状態が変化が多数ある場合に条件分岐を使うことなく状態変化を実現できます
状態毎のオブジェクトを作っておいて、状態を変えたいときは
コンテキスト内の状態オブジェクトを変更するだけで振舞いを容易に変更できます
Ryo Fujimoto fujimisakari
階層構造を持つオブジェクトへアクセスしたいときに、
親オブジェクトと子オブジェクトに同じインターフェースを定義することで、
階層構造を意識せずにアクセスすることができる。
ツリー構造や配列構造のように複雑な構造で保持されているオブジェクトがあるときに、
対象オブジェクトの構造を意識しない簡単な操作で対象オブジェクトの構造を扱うことでできる。
HeadFirstデザインパターンでの定義
アルゴリズム実現するためのテンプレート作成するパターンになります。
同じような処理が複数あるとき、基本操作(primitiveOperation)をサブクラスでオーバーライドすることで、
全体を共通化しながら、バリエーションによる影響を局所的に抑えられます
Facadeパターンは、何らかのサブシステムに属する一連の複雑なクラスを
簡素化して統合するFacadeクラスを作成します。
クライアントはサブシステムのこと何も意識せずにFacadeクラスのみに依存した
最小構成のシステムを実現できます。
オブジェクトをラップし、別のインタフェースを提供します。
※ アダプタ、デコレータ、ファサードパターンの違い
アダプタは、オブジェクトのインタフェースを変更するためにラップします。
ただ1つだけのオブジェクトが作成されていることを保証します。
HeadFirstデザインパターンでの定義
Commandパターンは、リクエストを行うオブジェクトと、その実行方法を
知っているオブジェクトを分離させます。
そして、どのリクエストにも対応できるよう共通のAPIを持ち合せており
異る種類のリクエストでも同様の呼び出しでアクションを実行させることできる
サブクラスが作成する具象クラスを決定します。
インスタンス化したいオブジェクト(製品)を実行時の条件によって決めたい場合に利用します。
ただ、FactoryMethodパターンはオブジェクト(製品)を生成する側と利用する側を分けて定義する必要があります。
分けておくことで、将来システムに起こり得る変更をあらかじめ分離でき保守性を保つことができます。
NewerOlder