Structural pattern

Facade Pattern

Creational patterns Structural patterns Behavioral pattern J2EE patterns Abstract Factory Adapter  Chain of Responsibility MVC  Builder Bridge  Command  Business Delegate Factory method Composite  Interpreter  Composite Entity Prototype Decorator  Iterator  Data Access Object Singleton Façade Mediator  Front Controller Flyweight  Memento  Intercepting Filter Proxy  Observer  Service Locator State  Transfer Object Strategy  Template Method Visitor

Facade Pattern

Define facade pattern

Make a complex system simpler by providing a unified or general interface, which is a higher layer to these subsystems.

Where to use & benefits

Want to reduce complexities of a system. Decouple subsystems , reduce its dependency, and improve portability. Make an entry point to your subsystems. Minimize the communication and dependency between subsystems. Security and performance consideration. Shield clients from subsystem components. Simplify generosity to specification. Related patterns include Abstract Factory, which is often used to create an interface for a subsystem in an independent way, and can be used as an alternative way to a facade. Singleton, which is often used with a facade. Mediator, which is similar to facade, but a facade doesn't define new functionality to the subsystem.

Example of facade pattern

JDBC design is a good example of Façade pattern. A database design is complicated. JDBC is used to connect the database and manipulate data without exposing details to the clients. Security of a system may be designed with Façade pattern. Clients' authorization to access information may be classified. General users may be allowed to access general information; special guests may be allowed to access more information; administrators and executives may be allowed to access the most important information. These subsystems may be generalized by one interface. The identified users may be directed to the related subsystems. interface General {     public void accessGeneral(); } interface Special extends General {     public void accessSpecial(); } interface Private extends General {     public void accessPrivate(); } class GeneralInfo implements General {     public void accessGeneral() {     //...     }     //... } class SpecialInfo implements Special{     public void accessSpecial() {         //...     }     public void accessGeneral() {}     //... } class PrivateInfo implements Private, Special {     public void accessPrivate() {     // ...     }     public void accessSpecial() {     //...     }     public void accessGeneral() {     // ...     }     //... } class Connection {    //...        if (user is unauthorized) throw new Exception();    if (user is general) return new GeneralInfo();    if (user is special) return new SpecialInfo();    if (user is executive) return new PrivateInfo();    //... } The above code example illustrates that the whole system is not exposed to the clients. It depends on the user classification. Mr. SudHakar Chavali proposes a better design, similar to the above, but avoids repeated code. Look at code below. interface General {     public void accessGeneral(); } interface Special extends General {     public void accessSpecial(); } interface Private extends General {     public void accessPrivate(); } class GeneralInfo implements General {     public void accessGeneral() {     //...     }     //... } class SpecialInfo extends GeneralInfo implements Special{     public void accessSpecial() {         //...     } } class PrivateInfo extends SpecialInfo implements Private {     public void accessPrivate() {     // ...     }        //... } To avoid repeated code, SpecialInfo become subclass of GeneralInfo and PrivateInfo becomes subclass of SpecialInfo. When a person is exposed to special information, that person is allowed to access general information also. When a person is exposed to private information, that person is allowed to access general information and special information also.