2.6 Facade

The Facade pattern gives a complex set of subsystems one simplified, unified, high-level entry point. The client no longer faces seven or eight interlocking subsystem calls — just one clean facade method.

A home theater is the textbook example: watching a movie means dimming lights, lowering the screen, turning on the projector, configuring the amp, and starting the player. Without a facade, the client must remember every step and the right order; with one, theater.watchMovie() does it in a line.

The lab below contrasts "facade one-tap" with "manual step-by-step" so you feel how much complexity the facade hides behind it.

A facade orchestrates; it does not seal

class HomeTheaterFacade {
    public void watchMovie() {
        lights.dim(10);
        screen.down();
        projector.on();
        amp.surround();
        player.play();
    }
}

Two key points:

• The facade implements no business logic itself — it only orchestrates subsystems in a sensible order.

• The facade does not remove the right to access subsystems directly. A power user needing fine-grained control can still bypass it and call projector.on(). That distinguishes it from a "proxy/permission layer."

The lab below quantifies the simplification using "number of calls the client must issue."

Facade, Mediator, and API Gateway

• Facade vs Mediator: a facade is one-directional, client → subsystem; a mediator is bidirectional, coordinating multiple objects that talk to each other.

• Real-world echoes: an API Gateway in microservices, a backend Service layer, a simplified client exposed by an SDK — all are scaled-up versions of the facade idea: gather internal complexity behind one stable, friendly entry.