gof-facade

One-line summary

Provide a unified, simplified interface to a set of interfaces in a subsystem — making the subsystem easier to use without preventing direct access for power users.

When to use this skill

• A subsystem has many parts and most callers only want a small, common combination of operations on them.
• Onboarding new code into a complex codebase — Facade gives the new code one clean entry point.
• Wrapping a legacy or third-party library whose internal complexity should not leak everywhere.
• The canonical example: a "watch a movie" facade that turns on the TV, dims the lights, lowers the screen, switches the receiver to the right input, queues the popcorn maker, and starts the DVD — instead of having every caller orchestrate those steps.

When NOT to use this skill

• You're trying to replace the subsystem rather than offer a simpler entry point — that's a refactor of the subsystem.
• You're trying to change the interface of a single class — that's gof-adapter.
• The subsystem is genuinely small and a Facade would only add a layer of indirection.
• Callers actually need the full control the subsystem offers; a Facade that hides too much forces them to bypass it.

Core content

A Facade is a class that holds references to the subsystem classes it orchestrates and exposes a small set of high-level methods. Each method on the Facade composes multiple lower-level operations into a coherent unit of meaning at the level the caller cares about.

Key principle of Facade: it does not prevent access to the subsystem. Callers that need finer control can still reach in directly. The Facade is a convenience, not a wall.

Related principle that HFDP attaches to Facade: the Principle of Least Knowledge (the Law of Demeter). Facade methods talk to a small number of close collaborators rather than reaching deep into the subsystem from afar.

Decision heuristics

• A Facade method should read like a unit of user intent ("watchMovie", "shutdownProperly", "settleOrder") — not like a thin pass-through to one subsystem call.
• Keep the Facade itself stateless when possible; it should be orchestration, not state ownership.
• If you find yourself adding many setters to the Facade, it has stopped being a Facade.

Anti-patterns

• Facade that forbids direct subsystem access — a Facade is convenience, not a fortress.
• Facade with one method per subsystem method, named identically — that's a pass-through, not a Facade.
• Facade that grows to know every subsystem detail — at some point it stops being "high-level" and becomes a god class.
• Multiple Facades over the same subsystem, each adding a slightly different convenience — usually a sign that the underlying subsystem needs refactoring instead.

See also

• gof-adapter — when wrapping one class to a different interface; Facade wraps many classes into a simpler interface.
• gof-mediator (not covered here, GoF original) — Facade is one-directional (caller → subsystem); Mediator is bidirectional coordination between peers.
• gof-kotlin-idioms — top-level functions and extension functions in Kotlin often serve as lightweight facades without needing a class.

References

• Head First Design Patterns (2nd ed), Ch. 7 ("Being Adaptive: the Adapter and Facade Patterns") — the home theater example is the canonical illustration.