Facade Design Pattern

When Will We Need Facade Design Pattern?

Let us think of a situation where we want our code to work with a broad set of objects which belong to a framework or a library. In a normal situation, we will need to initialize all the objects and execute all the methods in the correct order by keeping track of dependencies.

Consider the startup of a computer, when a computer system starts up it involves work of memory, CPU, hard drive, etc. These are complex processes that need to be handled.

So, to overcome this problem we have introduced the Facade design patterns. Where we wrap the complexity of the task and provide one simple interface instead.

But, you might be thinking, how does Facade solve these problems? Let us take a real-world example to understand this.

Scenario A

When we call a shop to place an order the operator attending the call is our facade to all the services the shop can provide, so in simple terms, in facade design patterns we provide a simple interface before a complex system and based on the input in facade layer the job is assigned to the respective subsystem.

How Does Facade Design Pattern Work?

Structure of Facade Design Pattern

The structure of Facade Design Pattern based on scenario A can be represented as,

Now, Consider the diagram above the SHOP interface is a complex system, which has various functions such as Order, Delivery, Payment. But a user must have an idea about how and where these functions are implemented in the SHOP interface to be able to use them correctly. To avoid this problem we have created a Facade interface named Facade Pattern Client which accesses the Shopkeeper object to handle these requests in a systematic manner.

Now, let us try to implement facade design in scenario A.

PseudoCode :

We have in total, three functions that are needed to be implemented. Starting with,

PlaceOrder

The PlaceOrder class places the order and returns the status of the placed order. Then we have,

Payment

The Payment class returns the status of the payment made on its respective order.

Delivery

The Delivering class returns the status of delivery for the respective order placed.

As we can see these three functionalities are independent. So to manage these functionalities in a systematic manner we introduce the concept of Facade.

Facade

Here the Operator class acts as a facade to the entire shop system, where the client is provided access to only Operator class to access the PlaceOrder, Payment, and Delivery functionality.

What are the Pros and Cons of Facade Design Pattern?

Pros :

We can isolate the code complexities of a system.

Cons:

A Facade can become a Parent object coupled to all the classes, which means all the functions are dependent on the facade class.

Relation of Facade Design Pattern with Other Structural Design Patterns

• Abstract Factory design pattern acts as an alternative to Facade design pattern, Abstract factory design pattern is used when we want to hide the way of creating the subsystem objects from the client code.

• The Proxy design pattern is similar to Facade design pattern as both the patterns buffers a complex entity and initializes it on its own terms. But unlike the Facade pattern, the Proxy pattern is implemented on the same interface as it is a service object, which makes the Proxy pattern interchangeable.

• In the Facade pattern, we make a single object that represents the whole subsystem, whereas in the Flyweight pattern we distribute the system into a lot of little objects.

• In the Adapter pattern, we try to make the existing interface usable by wrapping just one object, whereas Facade defines a new interface for existing objects and works on the entire subsystem.