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.

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

Offers the simplified interface
Delegates requests to the subsystems

Package

Modernes C++ Mentoring

"Fundamentals for C++ Professionals" (open)

"Design Patterns and Architectural Patterns with C++" (open)

"C++20: Get the Details" (open)

"Concurrency with Modern C++" (open)

"Generic Programming (Templates) with C++": October 2024

"Embedded Programming with Modern C++": October 2024

"Clean Code: Best Practices for Modern C++": March 2025

Do you want to stay informed: Subscribe.

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:

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:

Containers of the Standard Template Library automatically manage their memory.
The threading API triggers calls to the underlying threading infrastructure, such as pthread or win32 threads.
The parallel STL calls the underlying infrastructure, such as the Threading Building Blocks (TBB) or the Parallel Patterns Library (PPL).
The filesystem library is an abstraction above the underlying operating system-specific filesystem library.
There are more operating system-specific abstractions. Here are a few: chrono library, random library, or the formatting library.

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.

Post Views: 5,418

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, 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, 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, Philipp Lenk, Charles-Jianye Chen, Keith Jeffery, Matt Godbolt, and Honey Sukesan.

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