The facade structural pattern provides a simplified way for you to interact with a more complicated set of interfaces.
This is a simple design pattern that you can use whenever you have a complicated class or set of classes that you want to provide a simpler and easier way for other code to use. It really just comes down to making a new class with a new interface that’s designed to solve the majority of use cases. You can still have some or all of the more complicated interfaces available if you want.
You can compare this facade design pattern with the adapter design pattern which should help explain both patterns. Both involve creating a new interface. the difference between the two patterns though is in their intention.
If you find yourself creating a new interface for another class or set of classes because the new interface is expected and needed by some other code, then you have an adapter.
And if you find yourself creating a new interface for another class or set of classes because the new interface is simpler and easier to use, then you have a facade. Listen for more or read the full transcript of the episode below.
Transcript
The basic description says that this pattern provides a single interface to a more complicated set of interfaces in a subsystem so that other programmers will have an easier time using the subsystem.
Have you ever worked in a team and needed to figure out a good way for your team to work with other teams? What did you do? Chances are, your team selected a representative as a point of contact for your team and it was the representative’s job to coordinate requests from other teams and isolate the rest of your team so you all could stay focused.
Or have you ever had a question or complaint from a large company and called them? Did you speak directly with the person who created the item or service that you were calling about? Probably not. I’d guess that you instead spoke with a customer support representative who either handled your issue right away or referred you to somebody else.
Or for a more technical example, have you ever driven an automatic car? You don’t have to worry about pressing the clutch or when to change gears. You just put the car in drive, take your foot off the brake pedal, and press the gas pedal.
These are all examples of the facade pattern.
The first example provides a single person who can route questions and comments to the appropriate team member who then reply back through the representative. As far as the other team members are concerned, the requests might just as well be coming from the representative.
The second example also uses representatives but at a higher level. These are not just team representatives but company representatives. This pattern can work with various levels.
The third example is possible because an automatic transmission provides a simple interface which can be passed on to the driver. There are still gears that need changing but the transmission deals with this part by measuring speed and the effort the driver is placing on the engine.
Having a facade in place doesn’t mean that it must always be used. A facade is usually created to solve the majority of issues in the most simple and direct manner possible. There will sometimes be situations that require access to the individual team members, or to the departments directly, or take manual control over when to change gears. You can still expose the more complicated systems if you need to. It all depends on what you’re trying to solve.
Wrapping up complicated systems or details behind a simple interface is usually a good idea.
And not only because it provides a simpler interface. If you can convince clients to use the facade instead of directly using more low level resources, then you have more ability to change those low-level systems without affecting the clients.
The facade pattern also helps you to layer your code. You may have a set of low level classes that offer so much ability that clients don’t know where to begin. A facade helps organize the low level layer classes into a simple interface that can be used by another layer. And you can continue exposing a single simple interface at each higher layer in your code.
Now that you know a bit about what the facade pattern can do and why, I’ll explain how it works and give you some tips right after this message from our sponsor.
( Message from Sponsor )
Creating a facade can sometimes be as simple as identifying common problems that other code needs help with and writing a class that exposes methods and properties to accomplish these. The implementation of the facade will be done by you or somebody familiar with how all the other code works. This means that another developer just needs to learn how to call the methods in the facade.
There are no fancy tricks with inheritance or object relationships. It all comes down to writing a class that knows how to interact with your other code so that other developers can focus on just working with your facade.
But what if you have some choices in exactly how to structure the facade solution. You could bundle multiple approaches into the facade and let the other developer select the options.
Or you could instead create an abstract facade interface with several concrete implementations where each implementation represents a different option. Then by selecting a particular concrete facade, it’ll behave accordingly. This keeps your facades simple because they can be switched out instead of trying to customize a single facade if different behaviors are needed. All you need then is an abstract factory to choose which facade will be used. Episode 63 describes abstract factories.
You might also wonder how the facade pattern compares with the adapter. Episode 64 describes the adapter pattern. While both patterns describe a process of creating a new class either for the facade or for the adapter, their purposes are different. An adapter changes an interface from usually a single object into something else that’s needed. And a facade creates an entirely different interface designed to be easier to use and understand. The facade normally simplifies and coordinates activities from potentially several other classes. The way to tell the difference between an adapter pattern and a facade pattern is to look at why the pattern is needed and not at how many classes are being wrapped. If the pattern is needed to create an interface that some other code expects, then you have an adapter. And if the pattern is needed to simplify, then you have a facade.