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