gof-facade

1行の概要

サブシステム内の複数のインターフェースに対して、統一された簡潔なインターフェースを提供します。サブシステムを使いやすくしながら、上級ユーザーが直接アクセスできるようにします。

このスキルを使う場面

• サブシステムに多くの要素があり、ほとんどの呼び出し元が、それらに対する一般的で限られた操作の組み合わせだけを必要としている場合。
• 複雑なコードベースに新しいコードを導入する場合。Facade は、新しいコードに明確なエントリーポイントを提供します。
• 内部の複雑さをあちこちに波及させたくない、レガシーライブラリやサードパーティ製ライブラリをラップする場合。
• 代表的な例：「映画を見る」ファサードを用意し、テレビをつけ、照明を暗くし、スクリーンを下ろし、レシーバーを適切な入力に切り替え、ポップコーンメーカーを起動し、DVDを再生する処理をまとめます。呼び出し元が毎回それらの手順を調整する必要はありません。

このスキルを使わない場面

• サブシステムに簡潔なエントリーポイントを提供するのではなく、サブシステム自体を置き換えようとしている場合。これはサブシステムのリファクタリングです。
• 単一のクラスのインターフェースを変更しようとしている場合。これは gof-adapter の役割です。
• サブシステムが本当に小さく、Facade を追加しても間接層が増えるだけの場合。
• 呼び出し元が実際にサブシステムの機能をすべて必要としている場合。隠しすぎる Facade は、呼び出し元に回避を強いてしまいます。

主な内容

Facade は、調整対象のサブシステムのクラスへの参照を保持し、少数の高レベルなメソッドを公開するクラスです。Facade の各メソッドは、複数の低レベルな操作を、呼び出し元が重視するレベルで意味のまとまりとなるように組み合わせます。

Facade の重要な原則は、サブシステムへのアクセスを妨げないことです。より細かな制御が必要な呼び出し元は、引き続きサブシステムに直接アクセスできます。Facade は便利な窓口であり、壁ではありません。

HFDP が Facade と関連づけている原則として、最小知識の原則（デメテルの法則）があります。Facade のメソッドは、遠くからサブシステムの奥深くにアクセスするのではなく、少数の近しい協力者とやり取りします。

判断のヒューリスティクス

• Facade のメソッドは、「watchMovie」「shutdownProperly」「settleOrder」のように、ユーザーの意図を表すまとまりとして読めるべきです。サブシステムの呼び出しをそのまま薄く中継するものにしてはいけません。
• 可能であれば、Facade 自体はステートレスに保ちます。役割は処理の調整であり、状態の所有ではありません。
• Facade に多くのセッターを追加していることに気づいたら、それはもはや Facade ではありません。

アンチパターン

• サブシステムへの直接アクセスを禁止する Facade。Facade は便利な窓口であり、要塞ではありません。
• サブシステムの各メソッドと同じ名前のメソッドを1つずつ持つ Facade。これは単なる中継であり、Facade ではありません。
• サブシステムのあらゆる詳細を把握するように肥大化した Facade。いずれ「高レベル」ではなくなり、神クラスになります。
• 同じサブシステムに対して、それぞれ少しずつ異なる利便性を加えた Facade を複数用意すること。通常は、代わりに基盤のサブシステムをリファクタリングすべき兆候です。

関連項目

• gof-adapter — 1つのクラスをラップして異なるインターフェースにする場合に使用します。Facade は複数のクラスをラップしてより簡潔なインターフェースにします。
• gof-mediator（ここでは扱いません。GoF の原典を参照）— Facade は一方向（呼び出し元 → サブシステム）ですが、Mediator は対等な要素間の双方向の調整を行います。
• gof-kotlin-idioms — Kotlin のトップレベル関数や拡張関数は、クラスを用意せずに軽量なファサードとして機能することがよくあります。

参考資料

• Head First Design Patterns（第2版）、第7章（「Being Adaptive: the Adapter and Facade Patterns」）— ホームシアターの例は、代表的な説明です。