5

新しいコンポーネントを設計しており、コマンド設計パターンの使用を検討しています。

インターフェイスを実装する 2 つの主なコマンド タイプがありますIOurCommand(そこから他のコマンドが継承されます)。

問題は、最初のコマンドCommandDoUpdatesは値を返す必要がないのに対し、2 番目のコマンドはデータをフェッチするため、いくつかのオブジェクトのCommandGetDataを返す必要があることです( )ListList<DataRow>

状況に対処するために私たちが検討していること：

  1. 操作の成功に関する指示 (ボーナス) を含む Class と、すべての の空のリストになるオブジェクトの List を返しますCommandDoUpdates。
  2. 具体的なコマンドのメンバーとして保持するList- 潜在的な解決策ですが、他の理由で私たちの生活を困難にします (浅いコピーと深いコピーなど)。
  3. #1 と同じですが、関数内で基本クラスを返します。呼び出し元のすべての呼び出しは、結果を具体的なクラスにダウン キャストする必要があります (クライアントは実際の戻り値を知る必要があるため、ダウン キャストはお勧めできません) ）。
  4. コマンドを 2 つの異なる階層 (値を返すものと返さないもの) に分割し、2 つの異なるレシーバーを使用する - 私は本当に好きではありませんが、それはオプションです。

この投稿は、コマンドが値/ステータスを返す必要があるかどうかについての良い読み物です。これは、GoF の本では Command 設計パターンが値を返さないため、関連しています。

私の実際の質問は次のとおりです。

  • より良い解決策を考えられますか?
  • オプション 1、2、3 の長所と短所、オプション 4 の長所はありますか?

ありがとう！

4

2 に答える 2

1

コマンド パターンは、ここで実際にパターンを壊すところまで拡張されているのではないかと思います。リンクした投稿のコメントの 1 つは、次のように述べています。1 つのコマンド ファミリがデータにアクセスし、もう 1 つのコマンド ファミリがそれを変更する場合、それらを共通の型に抽象化する必要がある一般的なユース ケースは実際にありますか? 私にとって、一般的なインターフェースは、2 つのオブジェクトが同じように使用されると言っていますが、実際にはそうではありません。

より良い解決策として、一般的な解決策の 1 つは、MV* (MVC、MVP、MVVM) パターンを使用し、コマンドでモデルを更新し、更新後にオブザーバーに通知することです。

MV* があまりにも多くのパターンである場合は、4 が答えだと思います。共通のインターフェイスを取り除くだけです。レシーバーのメソッドをジェネリックにすることができるので、必ずしも 2 つのレシーバーを持つ必要はありません。ただし、CommandDoUpdates を処理するか、CommandGetData を処理するかによって、何か違うことをしなければならないと思うので、メソッドのオーバーロードは、「コマンド」の戻り値の型をチェックするよりも明確かもしれません。この場合、これらの「コマンド」が基本的に同じタイプであると言うよりも、受信者の署名に2つの異なるタイプのオブジェクトからメッセージを取得することを示す方が明確だと思います。

また、おそらく CommandDoUpdates はトランザクション スクリプトとして優れており、CommandGetData はリポジトリとして優れており、2 つの階層の名前を変更できますか? 文脈の中で何が最初にコマンドパターンにつながったのかについての情報はあまりなく、それが正しい選択ではない理由だけです。

于 2013-08-20T15:11:03.450 に答える
0

Command別の方法として、結果を返さなければならない を作成することもできます。

  • オブザーバーに通知する、または
  • ゲッターを介して取得できるメンバーに結果を保持します

その特定のコマンドを作成すると、それがその種類のものであることがわかっているので、コマンドが終了した後にオブザーバーを割り当てたり、結果を取得したりできると思います。

于 2013-08-21T11:19:49.690 に答える