Today, I write about the Facade Pattern. The Facade Pattern is a structural pattern and has one purpose: to provide a simplified interface to any complex system.
The key idea of the
Facade Pattern is to provide a simplified interface to a complex system, consisting of a set of interfaces. A facade defines a higher-level interface that makes the subsystem easier to use. The high-level interface intends not to support all use cases of the complex system, but only the most important. Despite the Facade Pattern for the simplified interface, it is often still possible to use the complex system directly.
The Facade Pattern is an ideal starting point for decoupling complex systems by introducing layers. Additionally, it can be used as a starting point for deprecating the old interface.
Here are the facts.
- Provides a simplified interface to a set of interfaces
- Simplified access to a complex system
- A complex system contains many dependencies which are decoupled through the facade
- Introduction of layers within a complex system; the layer help to decouple the complex system
- Offers the simplified interface
- Delegates requests to the subsystems
- Implements the functionality
- Knows nothing about the facade
The following example is from Wikibook C++Programming: code patterns design
// from https://en.wikibooks.org/wiki/C%2B%2B_Programming/Code/Design_Patterns#Facade
using namespace std;
class Alarm // (2)
cout << "Alarm is on and house is secured"<<endl;
cout << "Alarm is off and you can go into the house"<<endl;
class Ac // (3)
cout << "Ac is on"<<endl;
cout << "AC is off"<<endl;
class Tv // (4)
cout << "Tv is on"<<endl;
cout << "TV is off"<<endl;
class HouseFacade // (1)
void goToWork() // (
void comeHome() // (5) Facade
//Rather than calling 100 different on and off functions thanks to facade I only have 2 functions...
HouseFacade (line 1) provides simplifies the usage of the classes
TV (lines 2 to 4). The simplified interface consists of the two member functions
goToWork (line 5) and
comeHome (line 6). Both member functions encapsulate the original interface's underlying member functions and guarantee that the member functions are called in the correct sequence.
Finally, here is the output of the program:
The Facade is probably the most heavily used Design Pattern in C++.
In general, calling a function that triggers an operating system call applies the Facade Pattern. Here are a few examples:
- The Adaptor Pattern adjusts an existing interface, but the Facade creates a new, simplified interface.
- An Abstract Factory is an alternative way to create a subsystem abstraction transparently.
- The Mediator Pattern coordinates organization between objects, but the Facade creates a new, simplified interface.
- The Singleton Pattern can act as a single access point to a complex subsystem.
What are the pros and cons of the Facade Pattern?
Pros and Cons
- The complexity of the code can be hidden from the client.
- The misuse of the complex system is drastically reduced: "Make interfaces easy to use correctly and hard to use incorrectly." by Scott Meyer in his post "The Most Important Design Guideline?".
- It helps to port the complex system to another platform because the client only depends on the facade.
- A Facade may have too many responsibilities, and it ends in the antipattern God Object.
A Facade Pattern and a Singleton Pattern are pretty similar. They provide a single access point to a complex system. Consequentially, the pros and cons of the Singleton Pattern also apply to the Facade Pattern. Read more about the pros and cons of the Singleton Pattern in my previous post: "The Singleton: Pros and Cons".
In my next post, I present the remaining structural pattern from the book "Design Patterns: Elements of Reusable Object-Oriented Software": the Proxy Pattern. The Proxy Pattern is used as a placeholder for accessing another object.
Thanks a lot to my Patreon Supporters: Matt Braun, Roman Postanciuc, Tobias Zindl, G Prvulovic, Reinhold Dröge, Abernitzke, Frank Grimm, Sakib, Broeserl, António Pina, Sergey Agafyin, Андрей Бурмистров, Jake, GS, Lawton Shoemake, Animus24, Jozo Leko, John Breland, Venkat Nandam, Jose Francisco, Douglas Tinkham, Kuchlong Kuchlong, Robert Blanch, Truels Wissneth, Kris Kafka, Mario Luoni, Friedrich Huber, lennonli, Pramod Tikare Muralidhara, Peter Ware, Daniel Hufschläger, Alessandro Pezzato, Bob Perry, Satish Vangipuram, Andi Ireland, Richard Ohnemus, Michael Dunsky, Leo Goodstadt, John Wiederhirn, Yacob Cohen-Arazi, Florian Tischler, Robin Furness, Michael Young, Holger Detering, Bernd Mühlhaus, Matthieu Bolt, Stephen Kelley, Kyle Dean, Tusar Palauri, Dmitry Farberov, Juan Dent, George Liao, Daniel Ceperley, Jon T Hess, Stephen Totten, Wolfgang Fütterer, Matthias Grün, Phillip Diekmann, Ben Atakora, Ann Shatoff, Dominik Vošček, and Rob North.
Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, and Slavko Radman.
My special thanks to Embarcadero
My special thanks to PVS-Studio
My special thanks to Tipi.build
I'm happy to give online seminars or face-to-face seminars worldwide. Please call me if you have any questions.
Standard Seminars (English/German)
Here is a compilation of my standard seminars. These seminars are only meant to give you a first orientation.
- C++ - The Core Language
- C++ - The Standard Library
- C++ - Compact
- C++11 and C++14
- Concurrency with Modern C++
- Design Pattern and Architectural Pattern with C++
- Embedded Programming with Modern C++
- Generic Programming (Templates) with C++
- Clean Code with Modern C++
- Phone: +49 7472 917441
- Mobil:: +49 176 5506 5086
- German Seminar Page: www.ModernesCpp.de
- Mentoring Page: www.ModernesCpp.org