patterns

The Facade Pattern

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.

 patterns

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.

Facade Pattern

Purpose

  • Provides a simplified interface to a set of interfaces

Use Case

  • 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

Structure

Facade

 

Rainer D 6 P2 500x500Modernes C++ Mentoring

Be part of my mentoring programs:

  • "Fundamentals for C++ Professionals" (open)
  • "Design Patterns and Architectural Patterns with C++" (open)
  • "C++20: Get the Details" (open)
  • "Concurrency with Modern C++" (starts March 2024)
  • Do you want to stay informed: Subscribe.

     

     

    Facade

    • Offers the simplified interface
    • Delegates requests to the subsystems

    Package

    • Implements the functionality
    • Knows nothing about the facade

    Example

    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
    
    #include <string>
    #include <iostream>
    
    using namespace std;
    
    class Alarm                                                            // (2) 
    {
    public:
    	void alarmOn()
    	{
    		cout << "Alarm is on and house is secured"<<endl;
    	}
    
    	void alarmOff()
    	{
    		cout << "Alarm is off and you can go into the house"<<endl;
    	}
    };
    
    class Ac                                                              // (3)
    {
    public:
    	void acOn()
    	{
    		cout << "Ac is on"<<endl;
    	}
    
    	void acOff()
    	{
    		cout << "AC is off"<<endl;
    	}
    };
    
    class Tv                                                              // (4)
    {
    public:
    	void tvOn()
    	{
    		cout << "Tv is on"<<endl;
    	}
    
    	void tvOff()
    	{
    		cout << "TV is off"<<endl;
    	}
    };
    
    class HouseFacade                                                    // (1)
    {
    	Alarm alarm;
    	Ac ac;
    	Tv tv;
    
    public:
    	HouseFacade(){}
    
    	void goToWork()                                              // ( 
    	{
    		ac.acOff();
    		tv.tvOff();
    		alarm.alarmOn();
    	}
    
    	void comeHome()                                             // (5)       Facade 
    	{
    		alarm.alarmOff();
    		ac.acOn();
    		tv.tvOn();
    	}
    };
    
    int main()
    {
    	HouseFacade hf;
    
    	//Rather than calling 100 different on and off functions thanks to facade I only have 2 functions...
    	hf.goToWork();
    	hf.comeHome();
    }
    

     

    The class HouseFacade (line 1) provides simplifies the usage of the classes Alarm, Ac, and 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:

     facadePattern

    The Facade is probably the most heavily used Design Pattern in C++.

    Known Uses

    In general, calling a function that triggers an operating system call applies the Facade Pattern. Here are a few examples:

    Related Patterns

    • 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

    Pros

    • 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.

    Cons

    • 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“.

    What’s Next?

    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, 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, 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, Rob North, Bhavith C Achar, Marco Parri Empoli, moon, Philipp Lenk, Hobsbawm, and Charles-Jianye Chen.

    Thanks, in particular, to Jon Hess, Lakshman, Christian Wittenhorst, Sherhy Pyton, Dendi Suhubdy, Sudhakar Belagurusamy, Richard Sargeant, Rusty Fleming, John Nebel, Mipko, Alicja Kaminska, Slavko Radman, and David Poole.

    My special thanks to Embarcadero
    My special thanks to PVS-Studio
    My special thanks to Tipi.build 
    My special thanks to Take Up Code
    My special thanks to SHAVEDYAKS

    Seminars

    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++
    • C++20

    Online Seminars (German)

    Contact Me

    Modernes C++ Mentoring,

     

     

    0 replies

    Leave a Reply

    Want to join the discussion?
    Feel free to contribute!

    Leave a Reply

    Your email address will not be published. Required fields are marked *