design patterns ·
Facade
Provides a simplified interface to a complex subsystem, hiding its internal complexity from clients.
Theory
Explanation
Intuition first, formal definition second. Skim the bullets if you already know this; read the prose if you don't.
When a subsystem has many classes with complex interactions, a facade provides a single simple class that covers the most common use cases - clients use the facade instead of navigating the subsystem directly.
The Facade delegates client requests to the appropriate subsystem objects. It knows which subsystem class is responsible for each request and how to sequence the calls.
When to use
Simplifying library usage, providing a clean API over complex legacy systems, startup/shutdown sequences, layered architecture boundaries.
When not to
When clients need full subsystem control. When the subsystem is simple enough to use directly.
Key insights
- Facade does not prevent direct subsystem access - it provides a convenience layer
- Multiple facades can exist for the same subsystem (different simplifications for different clients)
- Unlike Adapter, Facade does not wrap one interface into another - it creates a new higher-level interface
- Common in framework initialization: Spring ApplicationContext is a facade over the bean factory