Design Patterns Simplified - Part 8 (Facade)

I am here to continue the discussion around design patterns. Today, we will go through one of the structural design patterns called Facade.

Before talking about its implementation, let’s begin by defining it.

As per GOF guys, Facade pattern is defined as:

“Provide a unified interface to a set of interfaces in a subsystem. Façade defines a higher-level interface that makes the subsystem easier to use.”

All right! Let’s understand what they mean.

It means that when you have several sub-systems or classes, it’s often difficult for a client to interact with all of them, and if somehow the client manages to interact, the code becomes messy and difficult to maintain for any future change.

How Façade pattern works

Facade addresses the same problem by having just one interface (or wrapper class) to interact with client for all of its need. The wrapper class, internally handles all the complexity of interactions with other sub-systems.

Let’s understand this by a simple example.

We will take the same car example to illustrate the concept.

Let’s begin with building the sub-systems classes as in the following:

So, the sub-system is built now. Now, let’s design our Facade class which will talk to the client by some public methods exposed by it.

In the CarFacade class, you can see that we have exposed a public method called AssembleCar to which client will have access. Internally AssembleCar is handling complexity of interactions with sub-systems like Body, Engine, etc.

Now all the required setup is ready, let’s see how client uses this.

Output

So as you can see that client only knows about a façade method called AssembleCar and is successfully able to assemble the car without going into the complexity of various sub-systems involved.

Class Diagram