2.1 状態
状態は動作設計パターンです。これは、プログラムの実行中に、オブジェクトの状態に応じて動作を変更する必要がある場合に使用されます。
パターンは 3 つのブロックで構成されます。
コンテキストは、オブジェクトの動作が状態に応じて変化するクラスです。
状態は、各具象状態が実装する必要があるインターフェイスです。このインターフェイスを通じて、Context オブジェクトはメソッド呼び出しを委任することで状態と対話します。インターフェイスには、動作を変更するオブジェクトへのフィードバック手段が含まれている必要があります。
このために、イベントが使用されます(パブリッシャー - サブスクライバーのパターン)。これは、プログラムの実行中にイベントが発生したときに状態オブジェクトを置き換えるために必要です。Context 自体が定期的に状態オブジェクトに遷移をポーリングする場合があります。
ConcreteState1、ConcreteState2 - 具象状態のクラス。どのような条件下で、オブジェクトが現在の状態からどのような状態に移行できるかに関する情報が含まれている必要があります。たとえば、オブジェクトは ConcreteState1 から ConcreteState2 および ConcreteState3 に移動し、ConcreteState2 から ConcreteState1 に戻ることができます。いずれかのオブジェクトには、作成時にコンテキストが含まれている必要があります。
たとえば、キャラクターが走ったり、泳いだり、飛んだりできるゲームを作成しているとします。キャラクターが水に入った場合、水中での行動を制限するのが合理的です。現在、キャラクターは射撃できませんが、前方、右、左などに泳ぐなど、いくつかのアクションは可能です。
キャラクターの状態は、State オブジェクトによって記述できます。State オブジェクトには、呼び出して何かを実行するメソッドがあります。そして、キャラクターが水に入った後、その中の別の State オブジェクトへの参照を変更するだけで、その状態が変わります。
2.2 戦略
戦略は、アルゴリズムのファミリーを定義し、それぞれをカプセル化し、それらを交換可能にするための動作設計パターンです。これにより、適切なクラスを定義してアルゴリズムを選択できます。
Strategy パターンを使用すると、それを使用するクライアント オブジェクトに関係なく、選択したアルゴリズムを変更できます。
Strategy パターンを使用すると、コンテキストに応じてさまざまなビジネス ルールやアルゴリズムを使用できます。これは、システム (またはその環境) の現在の状態に応じて、同じ場所で異なるアルゴリズムを使用する必要がある場合に使用されます。
強み:
- さまざまなアルゴリズムの実装がカプセル化されているため、システムはビジネス ルールの変更の可能性から独立しています。
- すべてのアルゴリズムを 1 つの標準的な方法で呼び出す。
- スイッチや条件文は使用しません。
このパターンは State パターンに似ていますが、ここでは状態ではなく動作に重点が置かれています。ゲームのキャラクターが武器を変更できるとします。そうすれば、武器を変更するときに、この武器がどのように機能するかを説明するオブジェクトへの参照を変更するだけで済みます。
2.3 テンプレートメソッド
抽象クラス(抽象クラス) - アルゴリズムのステップを実装するために継承内で置き換えられる抽象操作を定義します。アルゴリズムのスケルトンを定義するテンプレート メソッドを実装します。テンプレート メソッドは、Abstract クラスで定義された置換操作およびその他の操作を呼び出します。
具象クラス(具象クラス) - 実装に必要な方法で置き換えられた操作を実装します。Concrete クラスは、アルゴリズムの不変ステップが AbstractClass で実行されることを前提としています。
このパターンは、必要な場合によく使用されます。
- アルゴリズムの不変部分を 1 回のみ使用し、変更部分は相続人の裁量に任せます。
- 重複を避けるために、いくつかのクラスに共通するコードのローカライズと分離。
- 継承者が特定の場所でのみコードを拡張できるようにします。
はい、このパターンでは、抽象クラスとその実装のペアの使用について説明します。
2.4 責任の連鎖
責任の連鎖は、システム内の責任のレベルを組織化するために設計された動作設計パターンです。
このテンプレートは、次のような状況での使用が推奨されます。
- 開発されたシステムには、特定の種類のメッセージを処理できるオブジェクトのグループがあります。
- すべてのメッセージは少なくとも 1 つのシステム オブジェクトによって処理される必要があります。
- システム内のメッセージは、「自分で処理するか、別のメッセージに渡す」スキームに従って処理されます。つまり、一部のメッセージは受信したレベルで処理され、その他のメッセージは別のレベルのオブジェクトに転送されます。
2.5 思い出
Keeper (Memento) は、カプセル化に違反することなくオブジェクトの内部状態を修正して保存し、後でこの状態に復元できるようにする動作設計パターンです。
Guardian パターンは次の場合に使用されます。
- 後で復元できるように、オブジェクト (またはその一部) の状態のスナップショットを保存する必要があります。
- オブジェクトの状態を取得するための直接インターフェイスは、実装の詳細を公開し、オブジェクトのカプセル化を破壊します。
GO TO FULL VERSION