Overview

Many complex systems are reducible to just a couple of their use cases, exposed by the subsystems. By doing so, the client code does not need to know about the internals of the subsystem. In other words, the client code is decoupled from it and it takes less time for the developer to use it.

This is known as a facade pattern, where the facade object is responsible for exposing all the subsystem’s functionality.

This concept resembles encapsulation, where we hide the internals of an object. With the facade, we hide the internals of a subsystem and expose just the essentials. The consequence is that the user is limited to the functionality exposed by the facade and is not able to use/reuse specific functionality from the subsystem.

It provides a unified interface to a set of interfaces in a subsystem. This simplifies the usage of big and complex systems by providing the interface for the most important use cases.

Facade Design Pattern
Facade Design Pattern
Implementation

The following diagram shows how a subsystem’s usage can be simplified and decoupled from the client code. The façade is the entry point to the subsystem; therefore, the subsystem code can easily be switched to a different implementation. The client dependencies can also be managed more easily and are more visible:

Where to use Facade Pattern?
  1. There are many dependencies between clients and the implementation classes of an abstraction. Introduce a facade to decouple the subsystem from clients and other subsystems, thereby promoting subsystem independence and portability.

  2. When you require to divide your subsystem, use of the facade to define an entry point to each subsystem level. If subsystems are dependent, then you can simplify the dependencies between them by making them communicate with each other solely through their facades.

  3. If you require to provide a simple interface to a complex subsystem. Subsystems often get more complex as they evolve. Most patterns, when applied, result in more and smaller classes. This makes the subsystem more reusable and easier to customize, but it also becomes harder to use for clients that don’t need to customize it. A facade can provide a simple default view of the subsystem that is good enough for most clients. Only clients needing more customizability will need to look beyond the facade.

Leave a Reply

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