第6章 Facadeパターン
鍵となる特徴
- 目的
- 既存システムの使用方法を簡素化したい。独自のインタフェースを定義する必要がある。
- 問題
- 複雑なシステムの一部だけを使用する必要がある、または特定の方法でシステムとやり取りを行う必要がある。
- 解決策
- Facadeによって既存システムを使用するクライアント向けの新たなインタフェースを用意する。
- 構成要素と協調要素
- 複雑なシステムの使用が容易になるよう、クライアントに対して簡潔なインタフェースを用意する。
- 因果関係
- Facadeは簡略したインタフェースを提供するが、すべての機能を提供するためのものではない(そのように作っては意味がない)。
- 実装
- 必要なインタフェース軍を持つ新たなクラスを定義し、このクラスから既存の(複雑な)サブシステムを必要なだけ呼び出す。
Facadeパターンの勘所
- システムの全てを把握していなければシステムを制御できないような状況を避け、必要な機能を楽に使えるようにしたい。
- そのような場合、システムを利用する方法と、利用目的に沿って最適化されたAPIを決定し、その呼び出し口だけを用意してやれば良い。
- これによって、システムの隅々まで把握していなくても、特定の目的ごとに必要なAPIを叩くだけで済む。
- このようなアプローチがうまく働くのは、システムの一部の機能だけを用いる場合や、特定の固定の形式でシステムとやり取りをする場合のみである。
- サブシステムとクライアントを分離し(サブシステムをカプセル化し)、クライアント側から特定の方法で目的に沿った処理を呼び出すだけで、複雑化したサブシステムを容易に利用できるようにする。これがFacadeパターンである。
- クライアントがやり取りするオブジェクトの数を減らす効果もある。クライアントとやり取りする代表のオブジェクト(見せかけのインタフェース=Facade)を一つ用意してやり、そのオブジェクトへの命令を介して他のオブジェクトへの命令を行わせることが出来る。
- システムへのアクセスをすべてFacade経由とすることで、システムの利用状況の監視・集計なども容易になる。
- システムの中身が全く別物に変わってしまっても、クライアント側から見えているのはFacadeが用意しているインタフェースのみなので、少なくともクライアント側の実装は保護できる。
