The Façade pattern is a structural pattern that simplifies the access to a complex system. It is very similar to the Adapter pattern, but it creates a wall (a façade) between one or more subsystems. The big difference between the adapter and the façade is that instead of adapting an interface to another, the façade simplifies the use of a subsystem, typically by using multiple classes of that subsystem.

We can apply the same idea to shielding one or more programs, but in this case, we call the façade a gateway—more on that in Chapter 19, Introduction to Microservices Architecture.

The Façade pattern is extremely useful and can be adapted to multiple situations.

Goal

The Façade pattern aims to simplify the use of one or more subsystems by providing an interface that is easier to use than the subsystems themselves, shielding the consumers from that complexity.

Design

Imagine a system with a multitude of complex classes. Direct interaction between the consuming code and these classes can become problematic due to coupling, complexity, and low code readability and maintainability. The Facade design pattern offers a solution by providing a unified interface to a set of APIs in a subsystem, making it easier to use.The Facade class contains references to the objects of the complex subsystem and delegates client requests to the appropriate subsystem object. From a client’s perspective, it only interacts with a single, simplified interface represented by the Facade. Behind the scenes, the Facade coordinates with the subsystem’s components to fulfill the client’s request.We could create multiple diagrams representing a multitude of subsystems, but let’s keep things simple. Remember that you can replace the single subsystem shown in the following diagram with as many subsystems as you need to adapt:

 Figure 11.15: A class diagram representing a Façade object that hides a complex subsystem 

The Façade plays the intermediary between the Client and the subsystem, simplifying its usage. Let’s see this in action as a sequence diagram:

 Figure 11.16: A sequence diagram representing a Façade object that interacts with a complex subsystem 

In the preceding diagram, the Client calls the Façade once, while the Façade places multiple calls against different classes.There are multiple ways of implementing a façade:

• Opaque façades: In this form, the Façade class is inside the subsystem. All other classes of the subsystem have an internal visibility modifier. This way, only the classes inside the subsystem can interact with the other internal classes, forcing the consumers to use the Façade class.
• Transparent façades: In this form, the classes can have a public modifier, allowing the consumers to use them directly or to use the Façade class. This way, we can create the Façade class inside or outside the subsystem.
• Static façades: In this form, the Façade class is static. We can implement a static façade as opaque or transparent.

I recommend using static façades as a last resort because static elements limit flexibility and testability.

We look at some code next.