The facade is a very simple pattern intended to simplify the use of complicated APIs. It is presented as a single class with a straightforward interface which allows callers to execute common tasks. The Facade may wrap a type with a very complex interface or multiple components which need to be used together.
The Facade pattern simplifies the use of complex APIs by providing a higher-level, simplified interface.
- Using the simpler interface is just an option. Callers can still access the wrapped components for lower-level functionality.
- Complex interface is in fact, the consumer side too. The client code gets complicated and harder to maintain.
- Interface changes require refactoring on the caller side which can become a serious problem especially when relying on framework or software systems that are still under development or changed frequently.
- The Facade Pattern consolidates the functionality into a single class and hides the complexity by providing a simpler interface.
- Clients don’t have to use the complicated subsystem directly, instead, they communicate with the Facade.
- The Facade in turn, involves the APIs of the subsystem it simplifies.
- The Facade not only provides a simpler interface but it also decouples the client implementation from the complex API.
- If the subsystem interface changes, they only have to adapt the Facade class, not the client code.
A typical mobile app in today’s world needs a network layer which takes the responsibility of fetching or downloading the data. If that’s all what the network layer does then consumer of this layer has to take the responisibility of storing the data / files if success or retry if failed.
Using Facade Design Pattern we create a Downloader component which encapsulates the downloading and storing parts providing the user a sleek simple to use interface. The component can also internalise the retry parts and throw error only if unsuccessful on multiple attempts.
- The Facade Pattern wraps the types belonging to a complex subsystem and provides a unified higher level interface. Clients can use the type or the subsystem through a simpler API.
- Another benefit of the Facade Pattern is that it isolates the changes of the underlying type or subsystem from the callers so the client code must not be defactored when the wrapped type change.
- Use the Facade pattern to simplify the usage of complicated pulling designed interfaces or when adding a convenient layer makes sense.
- A correctly implemented Facade Pattern lets client use the common features of the wrapped subsystem without directly accessing the underlying types.
Disadvantage: Leaking the wrapped objects. Changes made to the underlying types will require modifications on the caller side too.