1. Introduction
Structural design patterns are about how classes and objects are put together. They keep large structures easy to manage and loosely tied together (decoupled). The Facade Pattern is one of them. A system may have many parts that are hard to use. A facade gives them one simple interface.
2. Facade Pattern
The Facade Pattern is a structural design pattern. It gives one simple interface to a complex subsystem (a group of classes that work together). It is a single entry point: clients (the code that uses the system) call the facade and never see the complex parts behind it.
Real-Life Analogy: Manual vs. Automatic Car
- Complex Subsystem (Manual Car): To drive a manual car, you must know several parts (clutch, gear shifter, accelerator) and use them in the right order. The driver manages every step.
- Facade (Automatic Car): An automatic car is a facade. It gives a simple interface ("Drive," "Reverse," "Park") over the complex gear mechanics. The driver (client) no longer works the clutch and gears. The automatic transmission does it inside.
In short, the manual car exposes the complexity, while the automatic car (the facade) simplifies it for the user.
3. Class Diagram
In the diagram, the client calls only MovieBookingFacade. The facade calls the five services behind a single method.
4. Problem It Solves
It solves the problem of using a complex subsystem. It hides the complexity behind one interface.
Imagine a movie ticket booking system. Without a facade, the client must call each of these itself:
PaymentServiceSeatReservationServiceNotificationServiceLoyaltyPointsServiceTicketService
With the Facade Pattern, the client calls a single class, MovieBookingFacade. That class calls all the services in the right order.
5. Pros and Cons
| Advantages | Disadvantages |
|---|---|
| Lightweight coupling: The client depends on less of the subsystem. | Fragile coupling: If the facade changes often, client code can still break. |
| Flexibility: Subsystems can change without breaking client code. | Hidden complexity: The complexity is still there, so deep debugging is harder. |
| Simplifies client design: Clients use one interface, not many complex objects. | Violation of SRP: A facade can take on too many jobs and become a "god object" (a class that does everything). SRP means one job per class. |
| Promotes layered architecture: The system is split into separate layers. | Difficult to trace: One more layer sits in between, so the flow is harder to follow. |
6. When to Use
You should use the Facade Pattern when:
- Subsystems are complex: The system has too many classes and links between them.
- Simplified API needed: You want a simple entry point for outside code.
- Reduce coupling: You want client code to depend less on each part of the subsystem.
- Clean layering: You want to split the system into layers to keep it modular.