Facade Pattern
Provide a unified interface to a set of interfaces in a subsystem.
Intent & Objective
Define a higher-level interface that makes a complex subsystem easier to use, sheltering client code from intricate internal dependencies and sequencing.
"Hotel guests do not need to study town maps, negotiate with taxi fleets, or coordinate tour schedules. The concierge desk provides a single unified point of contact that handles all logistics behind the scenes."
"One single telephone number connects you to billing, technical diagnostics, and warranty repair teams behind an automated routing desk."
"Entering your password on a laptop hides dozens of complex operations: mounting encrypted disk volumes, connecting to secure Wi-Fi, starting audio daemons, and syncing clock NTP servers."
The Problem
To accomplish a common task (e.g. video rendering or home theater startup), client code must initialize and coordinate 10 different subsystem classes in an exact sequence.
The Solution
Provide a Facade class containing straightforward methods like `watchMovie()` or `convertVideo()` that handle the initialization and orchestration of the subsystem behind the scenes.
Key Participants & Architectural Roles
Code Samples (Traditional OOP vs Functional Programming)
Available in C++, Python, and JavaParadigm Contrast: Traditional OOP vs Functional / Data-Oriented
In OOP, Facade is an orchestration class. In Functional Programming, a Facade is a single composed pipeline function combining multiple lower-level functions.
Advantages
- ✓ Isolates your code from the complexity of a subsystem
- ✓ Provides a clean entry point into complex third-party libraries or legacy monoliths
Trade-offs
- ✗ A facade can become a god object coupled to all classes of an app if not bounded
When to Apply
- → When you need to have a limited but straightforward interface to a complex subsystem
- → When you want to structure a subsystem into distinct layers
When to Avoid
- ! When clients need fine-grained control over low-level subsystem internals