10

CommandデザインパターンでInvokerクラスはオプションですか? クライアントは、具体的なコマンドとコマンドの受信者をインスタンス化する必要があります。クライアントは常に Invoker をインスタンス化し、コマンド オブジェクトを Invoker オブジェクトに渡す必要がありますか。後でクライアントがコマンドを実行する必要があるときはいつでも、クライアントは Invoker オブジェクトに尋ねるだけで、Invoker はコマンドを実行します (おそらくすぐに、または後で実行するためにコマンドをキューに入れることができます)。

それとも、これは逆ですか？クライアントがコマンドを同期的に実行する必要がある場合、クライアントは基本クラス インターフェイスを使用してコマンドを参照しますが、具体的なコマンドとレシーバーをインスタンス化します。クライアントがコマンドを実行する必要があるときはいつでも、クライアントは基本クラスのコマンド変数で実行メソッドを呼び出すだけですか? コマンドをいつ実行するかの追加ロジックが必要な場合、その追加ロジックを保持するために Invoker クラスが使用され、クライアントは Invoker オブジェクトと対話してコマンドを実行しますか?

4

2 に答える 2

6

コマンドパターンの目的は通常、1）異なる操作のセットが同じタイプを共有するようにして、同じコードで処理できるようにします。2）操作のマーシャリング/作成を操作の呼び出しから分離します。受信者は、目的2のために明示的に必要です。

作成直後に呼び出す場合、または受信者が呼び出し側の役割を果たしている場合、単一目的のスタンドアロン呼び出し側はありません。それが呼び出し元がないことを意味するかどうかは、本当に哲学的な質問です:)

このように見てください。作成、スケジューリング、および呼び出しを/can/分離できます。これは、それらを3つの別個のクラスとして実装する必要があるという意味ではありません。コマンドパターンのライフサイクルに関係するのは、論理的な役割にすぎません。

編集：単一責任の原則は、それらを分離する必要があると主張していると思いますが、共通の感覚などがあります:)地域の状況を遵守することができ、遵守する必要があります。

于 2012-10-15T07:10:16.273 に答える
1

ご存じのとおり、java.lang.Runnable は、Thread クラスが呼び出し元として機能するコマンド パターンの例の 1 つです。Runnable クラスのオブジェクトを Thread クラスに渡し、start/run と言います。

しかし、メイン スレッドを呼び出すことができるクライアント クラスを作成することはありません。

したがって、インボーカーはオプションではありませんが、クライアントと密接に結合されているわけではありません。したがって、コマンド パターンの UML は、クライアント クラスとインボーカー クラスの間の関係を示しません。

この質問に関連する別の回答。

于 2013-05-04T17:33:35.187 に答える