使い方
- インストールコマンドをコピーし、自分の環境へ導入する前にソースを確認します。
- 必要なツール、認証情報、対応環境を原文で確認します。
- 入力と成果物を指定し、出力を資料と照合します。
npx skills add https://github.com/yonatankarp/software-design-skills --skill gof-facade開始前の確認
- 導入にはモデル契約、API枠、ファイルへのアクセス許可は含まれません。
- スター数や導入数は活動の指標であり、独立した品質・安全性試験ではありません。
見出し、例、コード、表、リンク、参照画像を含む原文を表示しています。
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.
