Facade Design Pattern
Introduction
Hello all, today I back with another Design Patterns topic, and today I will share what i learned about Facade design pattern. I hope with this article you will know more about Facade design pattern and use it on your project.
What It Is?
The Facade design pattern is a structural pattern that simplifies access to a complex subsystem by providing a unified, high-level interface for the client. This pattern hides the internal details of the subsystems from the client, making it easier for the client to interact with the subsystems.
When To Use It?
Here are some scenarios where implementing the Facade design pattern can be beneficial to a project:
When the client needs a simple way to access complex subsystems.
When there’s a need to decouple the client from the subsystems.
When it’s important to reduce dependencies between the client and the subsystems.
When the client needs to access several related parts of subsystems through a single access point.
Why Implement It?
Here are some pros and cons to consider before implementing the Facade design pattern in a project:
Pros
Reduces the complexity of client code by unifying the interface that interacts with multiple subsystems.
Decouples the client code from the internal details of the subsystems, making it easier to change subsystem implementations without changing the client code.
Reduces the number of dependencies for the client, as it only interacts with a single facade instead of multiple subsystems.
Improves readability by hiding unnecessary details of the subsystem in the client’s code.
Enhances scalability by allowing new features to be added to the facade without modifying the existing subsystem classes.
Cons
Might become a "God Object" if it manages too many subsystems, making the system harder to maintain and violating the Single Responsibility Principle.
Might make debugging and extending the system challenging if it hides too much of the underlying complexity.
Might create a single point of failure that affects the entire system if it fails, as it often acts as the only access point to subsystems.
Might reduce flexibility for the client if it is designed to restrict direct access to subsystem components, which could limit the use of certain features or functionalities of the subsystems.
How To Implement It?
Here are the steps to implement the Facade design pattern in a project:
Identify the complex subsystem operations that the client needs to simplify.
Create a facade class that acts as a middle layer between the client and the subsystems.
In the facade class, create high-level methods that perform multiple subsystem operations.
In the client, use the facade class to replace all the subsystem operations.
Structure
Pseudocode
BEGIN CLASS SubsystemA
BEGIN PUBLIC PROCEDURE operationA()
PRINT "Running SubsystemA Operation"
END PROCEDURE
END CLASS
BEGIN CLASS SubsystemB
BEGIN PUBLIC PROCEDURE operationB()
PRINT "Running SubsystemB Operation"
END PROCEDURE
END CLASS
BEGIN CLASS SubsystemC
BEGIN PUBLIC PROCEDURE operationC()
PRINT "Running SubsystemC Operation"
END PROCEDURE
END CLASS
BEGIN CLASS Facade
PRIVATE FIELD subsystemA = new SubsystemA()
PRIVATE FIELD subsystemB = new SubsystemB()
PRIVATE FIELD subsystemC = new SubsystemC()
BEGIN PUBLIC PROCEDURE execute()
subsystemA.OperationA()
subsystemB.OperationB()
subsystemC.OperationC()
END PROCEDURE
END CLASS
BEGIN CLASS Client
BEGIN PRIVATE PROCEDURE useFacade()
FIELD facade = new Facade()
facade.Execute()
END PROCEDURE
END CLASS
Additional Information
I have discovered some additional information about Facade design pattern. If you have any additional information about Facade design pattern that you'd like to share, please feel free to leave a comment.
Facade Design Pattern VS Adapter Design Pattern
Both Facade and Adapter design patterns have similar code structures. Due to these similarities, choosing between them can be challenging. Here are some key factors to consider before making a decision:
The Facade design pattern focuses on simplifying the interaction with complex subsystems by providing a unified interface, while the Adapter design pattern focuses on making two incompatible interfaces work together by providing a translation layer between them.
The Facade design pattern usually works with a set of classes or an entire subsystem, whereas the Adapter design pattern works with a single class or component.
Further Discoveries
Here are some further discoveries I have gathered from various sources that may provide a deeper understanding of Facade design pattern:
The Facade design pattern doesn't require the client to use every operation in the subsystem because it only wraps the essential operations.
The Facade design pattern is often used in libraries and frameworks to provide a simplified interface for the user.
The Facade design pattern can be combined with the Singleton design pattern, especially when the facade represents a global point of access for various subsystems.
The Facade design pattern can be used to manage security features by controlling access to specific subsystems.
The Facade design pattern can act as a boundary between different layers in a layered architecture. For example, it can act as a boundary between the presentation layer and the business logic layer to simplify their interaction.
The Facade design pattern doesn't change the behavior of the subsystems but simply provides a simplified interface to them.
The Facade design pattern makes unit testing easier by simplifying the subsystems' interface, allowing tests to focus on the simplified interface instead of multiple subsystems.
