The Facade design pattern gives a single interface to a group of interfaces in a subsystem. This pattern creates a higher-level interface that makes the subsystem easier to use. A facade is a structural design pattern that gives a simpler interface to a library, framework, or any other complicated group of classes.
In basic terms, the Facade Design Pattern is used to hide the intricacies of a system and give an easy-to-use interface to the client via which the client may access the system. The Façade (typically a wrapper) stands on top of a set of subsystems and allows them to interact cohesively.
When working with a huge system, we may need to use the “facade” design pattern frequently in software design. When you wish to call several subsystems of a larger system from a single point, you’ll require a façade design pattern (just in terms of software from now on) (client).
Here is UML Diagram:
The client is contacting the Façade class, which interacts with numerous subsystems to make it simpler for the client to interface with them.
However, it is conceivable that the façade will have reduced capacity as compared to interacting directly with the subsystem, but it should include all of the capabilities that the client requires.
For example, if a consumer phones a restaurant to purchase pizza or other food, the operator on behalf of the business provides the voice interface, which serves as the façade for their customers.
Customers submit their orders simply by speaking with the operator, and they don’t have to worry about how they will prepare the pizza, what operations they will execute, what temperature they will cook at, and so on.
Similarly, we can see in our code example that the client is utilizing the restaurant façade class to order various varieties of pizza and bread without directly dealing with the subclasses.
It’s finally time to get into the real coding.
This is the pizza-specific interface.
This is a pizza delivery class that will deliver pizza to their customers. Other secret methods may exist in these methods, which the client is unconcerned with.
Likewise, this is the bread interface.
Bread provider class; Restaurant façade class which the client will utilize to purchase various pizzas or bread.
Now, let’s look at when we should utilize this pattern and what real-world circumstances we could encounter:
WHEN SHOULD YOU APPLY THIS PATTERN?
When there are numerous complicated subsystems and communicating with them separately is difficult/cumbersome, use this approach to simplify the problem.
EXAMPLE OF APPLICATION IN REAL LIFE:
Consider the case of a vehicle manufacturing firm. Assume an automobile design factory has units such as Create Engine, Create Body, and Create Interior. All of these diverse units are entirely responsible for the overall design of an automobile.
The shopkeeper serves as a facade for all of the merchandise.
For its clients, an online travel portal serves as a facade for various vacation/travel packages.
Customer service serves as a facade for a variety of services.
This pattern is used to create a simplified user interface that can be reused by other parts of the application. By understanding how the facade design pattern works, you will be able to create a more maintainable and standardized front-end for your applications.
It allows us to define a simplified interface that can be used by subclasses while hiding the details of the implementation. This is extremely useful in situations where we need to change the implementation without changing the interface. The pattern is designed to make the client code more flexible and reusable. It is also used to reduce the amount of code needed to create an interface.