4

Chain of Responsibility パターンの概念は理解していますが、間違って使用している可能性があります。

いくつかの種類の製品があり、これらの種類の製品ごとに表示されるインターフェイスを制御するコントローラーがあります。ユーザーが製品のタイプを選択すると、各コントローラーが適切なインターフェイスを表示して操作します。

このために、私は大丈夫とは思えない一連の責任パターンを使用しています。私がやっていることは、コントローラーのチェーンを作成することです。製品タイプのリクエストを受け取るとすぐに、それをコントローラーのチェーンに渡し、適切なコントローラーにリクエストを実装させます。

しかし、考えてみると、単純なファクトリを使用して同じことを実現できましたが、多くの条件文が含まれていました。

この状況での責任の連鎖の使用についてどう思いますか?

4

1 に答える 1

2

私にとって、この仕事は間違いなく責任の連鎖のためではありません。
通常、責任の連鎖では連鎖要素の順序が重要ですが、ここではそうではありません。

私は次のことをしようとします。
productType のキーとコントローラーの値を持つマップを含む何らかのレジストリを作成します。

実装例:

class ControllerRegistry
{
  //declaration for map and constructor

  public void Register(string productType, IProductController controller)
  {
    _map.Add(productType, controller);
  }

  public IProductController Find(string productType)
  {
    return _map[productType];
  }
}

また、アプリケーションの起動時に、メソッドを呼び出してすべてのコントローラーを登録する必要がありますControllerRegistry.Register。
メソッドを呼び出すことで、適切なコントローラーを取得しますControllerRegistry.Find。
責任の連鎖と比較して、製品タイプの数が多い場合、パフォーマンス ヒットを回避できます。

EDIT
同じタスク トピック複数のメッセージ タイプを処理するための設計パターン

于 2013-02-22T21:12:41.850 に答える