Since
2008
Since
2008
Since
2008
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.
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.
In my experience the common mistakes I have seen is,
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.
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 are closed for "Facade Design Pattern".
Good article man, good examples and key points.
Keep it going ;)
Clear :)
very nice article!
It Consists all the things like common mistakes, api example and real world example.. :)
Keep growing..
Is facade is similar to the concept ” Code for interface not for implementation”
How is it different from factory?
Very Good Article
Good article.
Very good article… Keep going …
nice article sir….
Like your way of explanation with real world example. Nice article.
Please explain coupling and cohesion
your way of explanation and view is very nice. Please provide programmatic explanation.
excellent!!
nicly explained but can any body give the code for the same
greate example and keypoints
@Ahmad, this is not an implementation of code for interface.
I will try to add some code example soon.
nice artical… :)
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??
Thanks for the above details. could you please explain JDO in java.
Design Pattern are explained very clearly and pointed out key areas..thanks
very nice article. IT will be more helpful if u add java code demonstrating FACADE
Very good Article
Keep it going :)
nice examples giving clear roadmap of design pattern
nice article
hi joe,
it’s a nice article can u provide this with small example.
Excellent!!
Simple and relevant information.
Excellent. Very clear concept
Very nice and well explained! Thanks!
clear explanation
excellent job done
Excellent. Very clear
very helpful, thanks a lot !
Got the concept clearly..but plz post a small scenario which uses struts2-jsps,tiles,facade,DVO,BO,DAO
Its needed in business applications
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
Good explanation with example. Thank You for your blogs.
Nice examples and guidance to avoid mistakes!
liked it!!
good article!!
relevant, clear and cool explanation.
Please add a code implementation.
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();
}
}
Joe,
Good Job !!
Adesh
Alles klar
I used facade for more than 1 yr, but today after reading this article many doubts got clarified. Thaks for such a lovely article.
Thanks for the explination
r@j
Good examples. In a typical 3 layer(presentation, service, dao)
the business layer and the dao layer interfaces could be considered facades. Right?
Its very good artical.
Please provide some java code example.
Please provide me some simplejava code example.
Thanks for the explanation and making it simple to understand the Design pattern.
very good article. thank you very much for the effort but why there’s no implementation example?
It’s really good explaining with examples
excellent article
its very neatly explained!!!!
wonderful explanation and nice example
Good article but should provide some code showing the working example of Facade Design pattern…
otherwise, theoretically it covers almost everything. :)
Nice example !
It will be great help if code also provided
Bullet points :-)
Excellent work….
Nice Explaination :)
Nice examples and metaphores but programmatically explaining will make life much more easier…anyways superb joe.:)
Nice article
Excellent article!!..Real world examples are good…
thank you very much sir i have understand well about facade can u please provide me documentation
can we say this facade as a front controller?
Simple example and clear…Keep sharing :)
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….
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
Very clear Article for Beginner.
Good Example, Good Job
If sample/example code was also included it would be further more useful.
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.
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.
Noted with Thanks Lokesh!!!
factory will return the object but in facade it is not
very nice
Nice article ……
Good Example. if you could attach the code for respective design pattern then, it would be realy good.
Sure Manoj, will write up some sample code and update the tutorial soon.
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.
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?
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.
nice tutorial.
Very nice easy to visualize it, by giving real world example. Thanks Keep it up :)
great depiction……
One of the best explanation i have read:)
Thank!!! God bless you Sir!!!
whats the difference between facade and a controler?
thanks…
Explained well bro :) can you plz post any Implementation ?? so that It will be much better one to understand.
Thanks!!!
// 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
Thanks a Million. Its helpful.
Thanks Jay
Hey good presentation. Could you please write on other patterns also?
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?
is Facade is reverse to the Adapter ?
Good one … Thanks :)
Good one
Excellent,
Keep it going…
Excellent.
Keep it going …
nice explaination…but where is the code????
Could u please post some sample code with explanation
Hi Joe
Thanks for your nice articles on Design Patterns. I found it really helpful in understanding design patterns
Thanks
Senthil
Very nice article
Nice article, explained so good and able to understand easily.
keep it up the good work.
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)
Thanks…Can you also wrote about visitor design pattern..
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?
Good one !!
good article..ur articles r always good and simple to understand..keep it up
Awesome article Joe, Keep up the good work
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.
superb explanation. Joe sir u have very good explanation power. It is the most important thing which few has it..
Great Explain
nice..quite clear
Thanks nice one to understand well…
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) .
Agreed.
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.
Very well and properly and clearly explained.
Thanks
very good article….keep it up…Excellent work