Facade Design Pattern

Last modified on September 12th, 2014 by Joe.

GoF definition for facade design pattern is, “Provide a unified interface to a set of interfaces in a subsystem. Facade Pattern defines a higher-level interface that makes the subsystem easier to use.”

How do we infer the above definition? Think of a component that solves a complex business problem. That component may expose lot of interfaces to interact with it. To complete a process flow we may have to interact with multiple interfaces.

To simplify that interaction process, we introduce facade layer. Facade exposes a simplified interface (in this case a single interface to perform that multi-step process) and internally it interacts with those components and gets the job done for you. It can be taken as one level of abstraction over an existing layer.

Facade design pattern is one among the other design patterns that promote loose coupling. It emphasizes one more important aspect of design which is abstraction. By hiding the complexity behind it and exposing a simple interface it achieves abstraction.

Real World Examples for Facade Pattern

I wish to give you couple of real world examples. Lets take a car, starting a car involves multiple steps. Imagine how it would be if you had to adjust n number of valves and controllers. The facade you have got is just a key hole. On turn of a key it send instruction to multiple subsystems and executes a sequence of operation and completes the objective. All you know is a key turn which acts as a facade and simplifies your job.

Similarly consider microwave oven, it consists of components like trasnformer, capacitor, magnetron, waveguide and some more. To perform an operation these different components needs to be activated in a sequence. Every components has different outputs and inputs. Imagine you will have separate external controller for all these components using which you will heat the food. It will be complicated and cumbersome.

In this scenario, oven provides you preprogrammed switches which can be considered as a facade. On click on of a single switch the job gets done. That single menu switch works as an abstraction layer between you and the internal components.

These are realworld examples for facade design pattern. In software scenario, you can have interfaces which acts as a facade. Methods in these interfaces contains the interaction sequence, formatting and converting data for input for components. As such it will not hold the business logic.

UML Diagram for Facade Design Pattern

Common Mistakes while Implementing Facade Design Pattern

In my experience the common mistakes I have seen is,

Summary of Facade Design Pattern

Facade Vs Mediator Design Pattern

Mediator design pattern may look very similar to facade design pattern in terms of abstraction. Mediator abstracts the functionality of the subsystems in this way it is similar to the facade pattern. In the implementation of mediator pattern, subsystem or peers components are aware of the mediator and that interact with it. In the case of facade pattern, subsystems are not aware of the existence of facade. Only facade talks to the subsystems.

Facade Design Pattern in Java API

ExternalContext behaves as a facade for performing cookie, session scope and similar operations. Underlying classes it uses are HttpSession, ServletContext, javax.servlet.http.HttpServletRequest and javax.servlet.http.HttpServletResponse.

Comments on "Facade Design Pattern"

  1. Alex says:

    Good article man, good examples and key points.
    Keep it going ;)

  2. Kat says:

    Clear :)

  3. Rajesh says:

    very nice article!
    It Consists all the things like common mistakes, api example and real world example.. :)

    Keep growing..

  4. Ahmad says:

    Is facade is similar to the concept ” Code for interface not for implementation”

  5. Suman says:

    How is it different from factory?

  6. Sudheer says:

    Very Good Article

  7. Itudoben says:

    Good article.

  8. Chaitanya says:

    Very good article… Keep going …

  9. Anonymous says:

    nice article sir….

  10. Dhiren says:

    Like your way of explanation with real world example. Nice article.

  11. cndhu says:

    Please explain coupling and cohesion

  12. Anonymous says:

    your way of explanation and view is very nice. Please provide programmatic explanation.

  13. Suyog says:

    excellent!!

  14. Anonymous says:

    nicly explained but can any body give the code for the same

  15. Manoj Dwivedi says:

    greate example and keypoints

  16. Joe says:

    @Ahmad, this is not an implementation of code for interface.

    I will try to add some code example soon.

  17. indrajeet says:

    nice artical… :)

  18. indrajeet says:

    can we able to get…application codes…?
    in case if we want code for some module to design an application…in java…
    is there any link or site available which will help us in such case??

  19. Sidharth says:

    Thanks for the above details. could you please explain JDO in java.

  20. santosh says:

    Design Pattern are explained very clearly and pointed out key areas..thanks

  21. Anonymous says:

    very nice article. IT will be more helpful if u add java code demonstrating FACADE

  22. Ranjit says:

    Very good Article
    Keep it going :)

  23. trim says:

    nice examples giving clear roadmap of design pattern

  24. prity says:

    nice article

  25. sivakumar says:

    hi joe,
    it’s a nice article can u provide this with small example.

  26. Naveen says:

    Excellent!!

    Simple and relevant information.

  27. Abir says:

    Excellent. Very clear concept

  28. Rodolfo Guzman says:

    Very nice and well explained! Thanks!

  29. prasanti says:

    clear explanation

  30. Anonymous says:

    excellent job done

  31. Anonymous says:

    Excellent. Very clear

  32. Anonymous says:

    very helpful, thanks a lot !

  33. Prafulla says:

    Got the concept clearly..but plz post a small scenario which uses struts2-jsps,tiles,facade,DVO,BO,DAO
    Its needed in business applications

  34. Raj says:

    theory explaind well , but try to add some real time examples or atleast links to examples of ur own, which helps for beginners and those who are intrested in learning java.

    Regards
    Raj

  35. Tribhuwan says:

    Good explanation with example. Thank You for your blogs.

  36. Mahsa says:

    Nice examples and guidance to avoid mistakes!

  37. Rajesh says:

    liked it!!

  38. pankaj says:

    good article!!

  39. Anonymous says:

    relevant, clear and cool explanation.
    Please add a code implementation.

  40. John Sambath says:

    Hi Joe, Based on your explanation I have written a sample, can the following code be a facade example? Please reply…

    package scjp;

    interface Car{
    public void start();
    }

    class Start implements Car{
    @Override
    public void start() {
    PowerIgnition pi = new PowerIgnition();
    pi.startPowerIgnition();
    Fuel f = new Fuel();
    f.startFuelFlow();

    }
    }

    class PowerIgnition{

    public void startPowerIgnition() {
    System.out.println(“Power Ignited from Battery”);
    }
    }

    class Fuel{
    public void startFuelFlow() {
    System.out.println(“Fuel flow started”);
    }
    }

    public class TestFacadePattern {

    public static void main(String[] args) {
    Car car = new Start();
    car.start();
    }
    }

  41. Anonymous says:

    Joe,

    Good Job !!

    Adesh

  42. Anonymous says:

    Alles klar

  43. Subrat says:

    I used facade for more than 1 yr, but today after reading this article many doubts got clarified. Thaks for such a lovely article.

  44. Anonymous says:

    Thanks for the explination

    r@j

  45. Anonymous says:

    Good examples. In a typical 3 layer(presentation, service, dao)
    the business layer and the dao layer interfaces could be considered facades. Right?

  46. Anonymous says:

    Its very good artical.

  47. Sanjukta says:

    Please provide some java code example.

  48. king says:

    Please provide me some simplejava code example.

  49. Nithiya says:

    Thanks for the explanation and making it simple to understand the Design pattern.

  50. Sezin Karli says:

    very good article. thank you very much for the effort but why there’s no implementation example?

  51. Sarath says:

    It’s really good explaining with examples

  52. rameez says:

    excellent article

  53. Srinivas says:

    its very neatly explained!!!!

  54. D.thirupathi says:

    wonderful explanation and nice example

  55. Rameshwar says:

    Good article but should provide some code showing the working example of Facade Design pattern…
    otherwise, theoretically it covers almost everything. :)

  56. Amol says:

    Nice example !

  57. Gurudas says:

    It will be great help if code also provided

  58. Anandhan says:

    Bullet points :-)

  59. Anonymous says:

    Excellent work….

  60. Anonymous says:

    Nice Explaination :)

  61. Saggy says:

    Nice examples and metaphores but programmatically explaining will make life much more easier…anyways superb joe.:)

  62. Anonymous says:

    Nice article

  63. SK says:

    Excellent article!!..Real world examples are good…

  64. rohit says:

    thank you very much sir i have understand well about facade can u please provide me documentation

  65. Anonymous says:

    can we say this facade as a front controller?

  66. Subha says:

    Simple example and clear…Keep sharing :)

  67. divya says:

    Nice explanation sir… But i have few doubts regarding this…
    U said that facade provides a single interface .If my business layer consists of 10 classes n assume each class has 3 methods then for a good facade design pattern implementation which of the following approaches are good?
    1)Mentioning all these 30 methods in a single interface?
    or
    2)Defining one interface with 3 methods. The other 9 classes extends the class that implements the interface?

    Please give your valuable reply n allow me to get clarified on this concept.
    Thanks in advance….

  68. Sameer says:

    Thanks Joe. I always try to brush up on the design patterns when there is a situation for a interview. Honestly never ever i came up with someone explaining these concepts as simple as you have explained out here. You are simply awsome. Thanks Again :)

    Sameer

  69. Preethi says:

    Very clear Article for Beginner.

  70. SandyaReddy says:

    Good Example, Good Job

  71. Manoswitha says:

    If sample/example code was also included it would be further more useful.

  72. Lokesh says:

    Hi Divya,
    It is not good to expose single interface with all the methods. It makes your classes grow in size Just remember the SPR principle it says your class should have only one reason to change. in your case you will have multiple reasons to change. So back to your question, I would say it is none. Facade pattern widely in use in EJB’s where remote calls are always going to be expensive. let’s say client(read it has struts actions or servlets or web services) need to use multiple business services(updations, deltions, insertiions using different business services) since these service invocations are really costly in case of remote invocations . It is better to create Facade which can encapsulate these subsystem invocations so that client can make only one single call which reduces the complexity involved in the client rather exposes unified interfaces to other clients which needs similar functionality(web services, rest , swings).

    Hope it helps.

  73. Lokesh says:

    Hi John,
    your example is good. But slight mistake though. Start cannot be a class . it is a verb and should be a method. rather you you have named it as CarFacade? for inheritance it should always pass ‘IS A’ test else it is wrong implementation of inheritance.

  74. John says:

    Noted with Thanks Lokesh!!!

  75. Anonymous says:

    factory will return the object but in facade it is not

  76. mall.rajeshmall@gmail.com says:

    very nice

  77. Anonymous says:

    Nice article ……

  78. manoj says:

    Good Example. if you could attach the code for respective design pattern then, it would be realy good.

  79. Joe says:

    Sure Manoj, will write up some sample code and update the tutorial soon.

  80. Kiran says:

    I have a query here, suppose there are 5 interfaces and each class implement only those which are needed, but if I create one common interface then implementing class will have to add method’s of all the methods given in 5 interfaces.

  81. avinash says:

    why do we need a Interface “OperationsFacade”in this pattern , whats the use of it . we could have just coded the “OperationsFacade” and made it a class. why do we first create a interface and then implement the interface?

  82. TomH says:

    Very good article. The only part I kind of disagree with is the GoF’s definition: “Provide a unified interface to a set of interfaces in a subsystem”.

    I would have defined it as: “Provide a customized interface to a subset of features in a subsystem or subsytems”.

    In other words, the facade only provides an interface to what the application actually needs, and it hides both unused interfaces and the complexity of using the underlying subsystem features that are needed by the application.

  83. deepak says:

    nice tutorial.

  84. Said Naeem Shah says:

    Very nice easy to visualize it, by giving real world example. Thanks Keep it up :)

  85. cherry says:

    great depiction……

  86. Bhasker Tiwari says:

    One of the best explanation i have read:)

    Thank!!! God bless you Sir!!!

  87. Qadeer Hussain says:

    whats the difference between facade and a controler?

  88. Kirtan says:

    thanks…

  89. Karthik says:

    Explained well bro :) can you plz post any Implementation ?? so that It will be much better one to understand.

  90. Jay says:

    Thanks!!!

  91. Jay says:

    // Diff complex parts or diff subsystems
    // 1. CPU
    public class CPU {
    public void execute() {
    System.out.println(“CPU EXECUTE – Done”);
    }
    }

    // 2. Memory
    public class Memory {

    public void load() {
    System.out.println(“MEMORY LOAD – DONE”);
    }

    }

    // 3. Harddrive
    public class HardDrive {

    public void read() {
    System.out.println(“READ HardDrive – Done”);
    }

    }

    // Facade which provides an interface for all complex part to be accessed through one facade class

    // Facade
    public class ComputerFacade {

    private CPU cpu;
    private Memory memory;
    private HardDrive hardDrive;

    public ComputerFacade() {
    this.cpu = new CPU();
    this.memory = new Memory();
    this.hardDrive = new HardDrive();
    }

    public void startComputer() {
    cpu.execute();
    memory.load();
    hardDrive.read();
    System.out.println(“Computer Successfully Started!!!”) ;
    }
    }

    // Client class which calls only facade interface to access diff complex functionality

    public class Test_FacadePattern {

    public static void main(String[] args) {
    ComputerFacade facade = new ComputerFacade();
    facade.startComputer();
    }
    }

    =============================

    Thanks

  92. Priyanka says:

    Thanks a Million. Its helpful.

  93. Manikumari Kancharla says:

    Thanks Jay

  94. Deepak says:

    Hey good presentation. Could you please write on other patterns also?

  95. Juan Manuel Mauricio Zamarrón says:

    Hi, I have a question, if I have a complex subsystem, and I have only one client who needs only some operations, is factible that I can use the facade pattern?

  96. ThirupathiReddy says:

    is Facade is reverse to the Adapter ?

  97. Subhajit says:

    Good one … Thanks :)

  98. Dilip says:

    Good one

  99. Emad Aghayi says:

    Excellent,
    Keep it going…

  100. Emad Aghayi says:

    Excellent.

    Keep it going …

  101. Anonymous says:

    nice explaination…but where is the code????

  102. Anonymous says:

    Could u please post some sample code with explanation

  103. SenthilRajan says:

    Hi Joe

    Thanks for your nice articles on Design Patterns. I found it really helpful in understanding design patterns

    Thanks
    Senthil

  104. Gopi says:

    Very nice article

  105. Shanmugam says:

    Nice article, explained so good and able to understand easily.

    keep it up the good work.

  106. JavaEnthusiast says:

    Thanks for pointing it. A minor correction, its Single Responsibility Principle (SRP). As per SRP, Every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. Robert C. Martin defines a responsibility as a reason to change, and concludes that a class or module should have one, and only one, reason to change. (courtesy Wikipedia)

  107. manu says:

    Thanks…Can you also wrote about visitor design pattern..

  108. Omar says:

    Thanks Joe. a doubt I have indeed. How come Facade and controller are different. The way i perceive controller is that, it is a class that juggles with several subsystems. If a client is directly calling Facade, may be in that case both are same?

  109. Manoj kataria says:

    Good one !!

  110. abhijeet says:

    good article..ur articles r always good and simple to understand..keep it up

  111. Aishvarya says:

    Awesome article Joe, Keep up the good work

  112. kishore says:

    I read some of the posts, you have explained in simple plain english with images and examples which is easier to understand. Keep it up this good work.

  113. Anonymous says:

    superb explanation. Joe sir u have very good explanation power. It is the most important thing which few has it..

  114. Sankar says:

    Great Explain

  115. hiti says:

    nice..quite clear

  116. abhimanyu says:

    Thanks nice one to understand well…

  117. Despot says:

    Hi,

    nope. Since those are interfaces, and the facade is an implementation that uses other interfaces/implementations.

    Additionally it should only have an additional formatting logic. No complicated stuff in there like dao usage for instance (since that is a (business) service responsibility) .

  118. Despot says:

    Agreed.

  119. Despot says:

    Hi Joe,

    good broad explanation, but I think you pinched some areas without fully going through them.

    “In software scenario, you can have interfaces which acts as a facade. Methods in these interfaces contains the interaction sequence, formatting and converting data for input for components. As such it will not hold the business logic.”

    Ok so by your definition you don’t consider accessing DAO layer from the facades method (only using the already provided business service methods and formatting them in any way).

    Than you go to say
    “A controller is not a facade.”.
    In a way a controller does the same thing. It uses business services methods and formats/packages the model in the way the client needs it. On the other hand, (the only difference I see using this definition) the facade can be used by other systems, not just like in a controller fashion through http.

    In that sense it looks to me that a facade is another type of business service that can emerge from other business used in a common way by two or more clients (clients being either internal or external systems).

    You would do the same even if you need to use a DAO layer (not only formatting and converting data). Imagine you have BusinessService1 with method do1() and BusinessService2 with do2() and you see 2 (or more) clients using
    model1 = do1()
    model2 = do2()
    model3 = persistOrRetrieveUsingSomeDAO(model1, model2)

    You will feel the urge to refactor this and place it in one place, implicitly creating another business service.

    So to me it boils down to using the SRP + IOC/DI + extracting duplicated logic. This will lead to any of the scenarios above.

  120. Krishna says:

    Very well and properly and clearly explained.
    Thanks

  121. kp says:

    very good article….keep it up…Excellent work

Comments are closed for "Facade Design Pattern".