Facade

The Problem It Solves

Playing one movie on a home theater the naive way: dim lights, lower blinds, start projector, set input HDMI-1, enable surround, launch player — six subsystem calls in the right order, known by heart by whoever set it up. Every client repeats that choreography; any subsystem change breaks all of them. Facade exposes one simple operation (watchMovie()) while the complexity stays coordinated behind it.

 WITHOUT FACADE                          WITH FACADE

 Client ──► Lights.dim()                 Client ──► HomeTheaterFacade
        ──► Projector.on()                              │ watchMovie()
        ──► Projector.setInput()                        │ coordinates:
        ──► Sound.on(); Sound.surround()                ▼
        ──► Player.play()                    lights → projector → sound → player
 6 calls × every client                      1 call; order owned in ONE place

 The waiter analogy: you never enter the kitchen —
 you order from one person who orchestrates the subsystems.

Mechanics

class HomeTheaterFacade {
    private final Lights lights;
    private final Projector projector;
    private final SurroundSound sound;
    private final Player player;

    public void watchMovie(String title) {
        lights.dim(20);
        projector.on();
        projector.setInput(HDMI_1);
        sound.on();
        sound.setSurround();
        player.play(title);
    }

    public void endMovie() {
        player.stop();
        projector.off();
        sound.off();
        lights.on();
    }
}

The facade adds no business logic of its own — it composes existing subsystem calls into meaningful high-level verbs.

What a Facade Is Not

Misconception	Correction
”Hides the subsystem completely”	Escape hatches remain — clients needing projector fine-control can still reach it
”Adds behavior like decorators”	Pure composition/orchestration; same-interface wrapping is decorator’s job
”A god service”	If it starts containing rules, it’s becoming a domain service — split

Real-World Sightings

• Service-layer classes over multiple repositories (OrderFacade.checkout() touching pricing + inventory + payment stores).
• SDKs: every StripeClient is a facade over raw REST choreography.
• Compilers: a single compile() fronting lexing/parsing/optimizing/codegen.
• Spring’s JdbcTemplate: facade over connection/statement/result-set lifecycle.

Why Teams Adopt It at Boundaries

• Reduces caller knowledge to a verb list — onboarding cost drops.
• Centralizes cross-subsystem ordering (the failure-prone part).
• Gives refactoring room: internals reshuffle freely as long as facade verbs hold.

Trade-offs

Gain	Cost
Simple client surface	One more layer to maintain
Subsystem evolution isolated	Risk of kitchen-sink facade if verbs accrete
Clear ownership of orchestration	Extra hop when callers needed fine control anyway

Interview Framing

• Asked to “design checkout,” introducing an OrderFacade coordinating pricing/inventory/payment — then stating “thin orchestration only; logic lives in each subsystem” — demonstrates both pattern and judgment.