Learn the Facade Design Pattern
This is the 11th post in a series on design patterns.
A facade is a structural design pattern that provides a simplified interface to a library, a framework, or any other complex set of classes.
Imagine that your code must work with a wide range of objects that are part of a library or framework. You would normally need to initialize all those objects, keep track of dependencies, execute methods in the correct order, and so forth. As a result, your business logic would become tightly coupled to the implementation details of 3rd party classes, making it difficult to maintain.
Facade Design Pattern
A facade is a class that provides a simple interface to a complex subsystem that has a lot of moving parts. Facades provide limited functionality in comparison to working directly with the subsystem. However, they only provide features that clients care about.
Facades are helpful when you want to integrate your application with a library that has dozens of features, but you only need a small portion of their functionality.
UML Class Diagram
Not familiar with UML Class Diagram? I have written a detailed post on the UML Class diagram.
Implementation steps
- Check if 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 of many of the subsystem’s classes.
- Implement this interface in a new facade class. Calls from the client code should be redirected to appropriate subsystem objects by the facade. The facade should be responsible for initializing the subsystem and managing its further life cycle unless the client code already manages this.
- If you want to get the full benefit from this pattern, all client code should communicate with the subsystem only through the facade. The client code is now protected from any changes to the subsystem code. As an example, when a subsystem is upgraded, you will only need to make changes to the facade code.
- Consider extracting some of a facade’s behavior into a new refined facade class if it becomes too large.
Source Code Implementation
A UPIPayment facade class offers convenient access to third-party services like banks and NPCI that facilitate UPI payments. This system knows where to direct clients’ requests and how to work with subsystems involved. This facade class provides two methods: one to register UPI addresses and another to make payments.
The NPCI class interacts with different banks to settle transactions between two bank accounts.
With a BankAccount class, you can manage the account of a customer who has registered their UPI address with their account to facilitate payments.
To track NPCI status for payment transactions, use the Enum Response.
A facade client class that calls the UPIPayment facade to complete the payment transaction.
// Output
Paid from abc@icici to xyz@axis, amount:100
When To Apply Facade Design Pattern
- When you need a limited but straightforward interface to a complex system, use the Facade design pattern. The Facade provides easy access to the most frequently used features of the subsystem.
- When structuring a subsystem into layers, use the Facade design pattern. Establish entry points to each level of a subsystem by creating facades. You can reduce coupling between multiple subsystems by requiring them to communicate through facades only.
Pros of Facade Design Pattern
- Code can be isolated from the complexity of a subsystem.
