2

Head First Design Patternsを読んでデザインパターンを学んでおり、StatePatternの章を終えたところです。しかし、私が得られないことが1つあります。

この本では、状態を持つクラスはContextと呼ばれ、実際の状態はStateインターフェイスを実装します。リクエストが本に与えられたら、ここのメソッドを使用して状態を変更します。

  1. コンテキストはリクエストを受け取ります。
  2. Contextは、所有するStateでhandle（）メソッドを呼び出し、要求をStateに渡します。
  3. 状態はリクエストを処理し、変更する必要がある場合はコンテキストに状態を設定します。これを行うために、州はフィールドとしてコンテキストを持っています。

ただし、これは2つのクラス間にいくらか「再帰的な」結合を与えるように思われ、直感的ではありません。私が彼らの解決策を読んでいないのなら、私は次のデザインを好むでしょう：

  1. コンテキストはリクエストを受け取ります。
  2. Contextは、所有するStateでhandle（）メソッドを呼び出し、要求をStateに渡します。
  3. 州はリクエストを処理し、州を返します。別の状態であるかどうかは、リクエストの処理方法によって異なります。
  4. コンテキストは、独自の状態を返された状態に設定します。

私が考えることができる長所と短所：

  1. 変化する可能性のあるすべてのものをStateクラス、Context、およびStateに入れると、互いのフィールドを覗き見する必要がなくなるため、より分離されます。
  2. 州のクラスは大きくなる可能性があります。
  3. 状態は、異なるコンテキスト間で簡単に再利用できない場合があります。ただし、Stateは、Stateインターフェースを実装する抽象クラスとして実装でき、抽象状態をサブクラス化するContextsによって使用される具体的なStateを持つことができます。

最初のもの（ Head First Design Patternsで使用されている）を優先する必要がある、または2番目の選択肢も有効で実際に使用されている、または私が見なかった重大な欠陥がある可能性がある特定の理由はありますか？

すべての入力と、読んで返信してくれてありがとう！

4

2 に答える 2

2

あなたが言及するアプローチの問題は、Stateオブジェクトへの参照を持つ他のオブジェクトが、あなたが説明するシナリオで更新を取得できないことです。説明すると、Stateは、更新されたStateを持つ別のStateを返すことができ、Contextは、Stateへの参照を更新されたStateに置き換えることができますが、Stateを参照する他のオブジェクトには、そうでないぶら下がり参照があります。コンテキストによって参照されます。

于 2011-08-02T18:22:22.377 に答える
1

3番目の方法は、コンテキストを状態のメンバーとして持つ代わりに、状態をシングルトンパターンとして実装し、コンテキストをパラメーターとして状態のイベントメンバー関数に渡す方法です。これは、フライウェイトパターンで使用されているのと同じテクニックです。このように、コンテキストのコロニーを使用することは可能ですが、各状態のインスタンスは1つだけです。

于 2011-08-03T17:19:06.050 に答える