Facade
Provide a unified interface to a set of interfacesin a subsystem. Facade defines a higher-level interface that makesthe subsystem easier to use.
Last updated
Provide a unified interface to a set of interfacesin a subsystem. Facade defines a higher-level interface that makesthe subsystem easier to use.
Last updated
Facade is a design pattern belonging to the Structural Pattern group.
Facade Pattern provides us with a simple common interface instead of a group of interfaces contained in a subsystem. The Facade Pattern defines a higher-level interface to help users easily use this subsystem.
The Facade Pattern allows objects to directly access this common interface to communicate with interfaces contained in the subsystem. The goal is to hide the complex operations within the subsystem, making the subsystem easier to use.
Frequency of use: quite high
When we have a sequence of actions that are performed in sequence, and these actions are required in many places within the scope of our application (for example when working with a large number of objects In a complex system or library, we need to initialize all of these objects ourselves, regularly monitor their changes, and the logical order must also be handled correctly with a third party. From there, the logic The operations of the classes become closely linked to the test library 3)
=> So every time you need to use it, you have to copy/paste or rewrite that code in the places you need to use it in the application. This also seems to help us get faster, but if we realize we need to change the structure and/or a certain piece of code in most of that sequence of actions, then how do we handle it?
This is the crux of the problem, we will have to search for that code in all places, and then fix it again. This is too time-consuming and, moreover, we lose control of our code and in the process there is a risk of errors. So what's the solution?
We need to design a Facade, and in it the Facade method will handle code that is used repeatedly. With Facade, we will simply call Facade to execute actions based on the parameters provided.
=> Now if we need any changes in the above process, the work will be much simpler, just change the processing in the façade, everything will be synchronized
When you call a shop to place a phone order, an operator is your facade to all services and departments of the shop. The operator provides you with a simple voice interface to the ordering system, payment gateways, and various delivery services.
Components in the model:
Facade: Facade understands which subsystem is responsible for meeting the client's request, it will transfer the client's request to the corresponding subsystem objects.
Addition Facade: can be created to avoid complicating a facade. Can be used by both the client and facade.
Complex Subsystems: Includes many different objects, installed with subsystem functions, handling work called by Facade. These classes do not need to know Facade and do not refer to it.
Client: Object uses Facade to interact with subsystems instead of calling subsystems directly
Facade objects are usually Singleton because only one Facade object is needed.
Advantage
We can separate our code from the complexity of the subsystem
System integration through Facade will be simpler because you only need to interact with Facade instead of a series of other objects.
Increase independence and mobility, reduce dependence.
It is possible to encapsulate many poorly designed functions as one better designed function.
Disadvantage
Your Class Facade may become too large, doing too many tasks with too many functions in it.
It's easy to break the rules in SOLID.
Using Facade for simple, not too complex systems becomes redundant.
Below we can list some cases where we should consider using the Facade pattern:
Want to group functions together to make it easier for Clients to use. When the system has many layers, it is difficult for users to understand the program's processing process. And when there are many subsystems and each subsystem has its own individual interfaces, it is difficult to use them in coordination. The Facade Pattern can then be used to create a simple user interface for a complex system.
Reduce dependency. When you want to layer subsystems. Use Façade Pattern to define common communication ports for each subsystem, thereby reducing the dependency of subsystems because these systems only communicate with each other through those common interface ports.
Increase independence and mobility
When users rely heavily on installation classes. Applying the Façade Pattern will separate the user subsystem and other subsystems, thereby increasing the independence and portability of the subsystem, making it easier to convert and upgrade in the future.
Packs a lot of functionality, hiding complex algorithms.
Need a hassle-free and easy-to-use interface.
Use the Facade pattern when you need to have a limited but straightforward interface to a complex subsystem.
Often, subsystems get more complex over time. Even applying design patterns typically leads to creating more classes. A subsystem may become more flexible and easier to reuse in various contexts, but the amount of configuration and boilerplate code it demands from a client grows ever larger. The Facade attempts to fix this problem by providing a shortcut to the most-used features of the subsystem which fit most client requirements.
Use the Facade when you want to structure a subsystem into layers.
Create facades to define entry points to each level of a subsystem. You can reduce coupling between multiple subsystems by requiring them to communicate only through facades.
For example, let’s return to our video conversion framework. It can be broken down into two layers: video- and audio-related. For each layer, you can create a facade and then make the classes of each layer communicate with each other via those facades. This approach looks very similar to the Mediator pattern.
Check whether it’s possible to provide a simpler interface than what an existing subsystem already provides. You’re on the right track if this interface makes the client code independent from many of the subsystem’s classes.
Declare and implement this interface in a new facade class. The facade should redirect the calls from the client code to appropriate objects of the subsystem. The facade should be responsible for initializing the subsystem and managing its further life cycle unless the client code already does this.
To get the full benefit from the pattern, make all the client code communicate with the subsystem only via the facade. Now the client code is protected from any changes in the subsystem code. For example, when a subsystem gets upgraded to a new version, you will only need to modify the code in the facade.
If the facade becomes too big, consider extracting part of its behavior to a new, refined facade class.
Abstract Factory can serve as an alternative to Facade when you only want to hide the way the subsystem objects are created from the client code.
Facade and Mediator have similar jobs: they try to organize collaboration between lots of tightly coupled classes.
Facade defines a simplified interface to a subsystem of objects, but it doesn’t introduce any new functionality. The subsystem itself is unaware of the facade. Objects within the subsystem can communicate directly.
Mediator centralizes communication between components of the system. The components only know about the mediator object and don’t communicate directly.
