Easy patterns: Facade
This article is created in continuation of easy patterns series description and presents a structural pattern named a Facade which solves the problem of interfaces set usage in some particular system by providing a higher-level interface.
Creational patterns:
Structural patterns:
Facade (this article)
Behavioral patterns:
The main essence
The Facade pattern is useful in cases when several subsystems have interfaces that has lack of common places, but it’s needed to provide a simple interface.
With development of application the included subsystems become smaller and more reusable and customizable. But in such way it becomes harder for the clients to utilize them, especially when there is no need to customize such subsystems.
The Facade pattern provides a simple default interface that is just enough for most clients. For those who need to get extra functionality and customizability it’s possible to look beyond the facade.
This pattern also helps to decouple clients from classes with hard implementation of abstraction. So clients would work only with simple and clear interfaces which represent only needed and predictable functionality.
This patterns includes two main roles:
- Facade — delegates call to specific subsystem class
- Subsystem — separate unit class which is responsible for concrete functionality
Example of use
Let’s create a coffee machine with some implemented methods inside, like: turnOn, turnOff, startHeating, brewCoffee, cleanMachine. For end user there is no need to do all the stuff, because manufacturer of coffee machine can make convenient buttons on the top of coffee machine with a handy programs under the hood. Like: makeCoffee and cleanMachine. Such top of coffee machine is named as a Facade. So user can just press one button and coffee machine will go through all lifecycle.
Profit
The Facade pattern saves clients from cooperation with distributed and complex subsystem classes through aggregated facade component with well known and documented API.
Using this pattern lets you vary the subsystem components and, therefore, reduce coupling between the client and components. This can help save time on recompilation in cases of subclasses change (like hot-swap).
Another benefit from usage of a Facade pattern is that it doesn’t prevent clients from using subsystem classes directly if they have to.
Usage of this pattern helps to reduce amount of user documentation, because it’s vital for user to know how to use Facade API and no need to dive deeply into subsystem implementation.
Weak places
Usage of this patterns leads to creation of extra class (a Facade) which can be an extra and useless effort, especially in cases when there are no great complexity expected from the system. The real benefit can be achieved only in big and complex systems with a big subsystem tree.
Conclusion
The Facade pattern can be used with (or even instead of) an Abstract Factory pattern. This helps to hide platform specific classes from the client.
Also the Mediator pattern is similar to the Facade. It abstracts a client from existing classes. But generally Mediator purpose is to abstract communication between subclasses and often centralizing functionality that doesn’t belong to any of them.
There is no need to have many Facade objects to communicate with the client. So, often they are a Singletons.
If you found this article helpful, please hit the 👏 button and feel free to comment below!
