2012-10-14 2 views
9

Invokerクラスはコマンドデザインパターンでオプションですか?クライアントは、コマンドの具体的なコマンドとレシーバをインスタンス化する必要があります。クライアントは常にInvokerをインスタンス化し、CommandオブジェクトをInvokerオブジェクトに渡す必要があります。クライアントがコマンドを実行する必要があるときはいつでも、クライアントはInvokerオブジェクトを要求し、Invokerはコマンドを実行します(すぐに実行するか、後で実行するためにコマンドをキューに入れることができます)。コマンドデザインパターン - 呼び出し側はオプションですか?

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

答えて

6

コマンドパターンの目的は、通常、1)さまざまな操作のセットを同じコードで処理できるように、同じタイプを共有するようにします。2)操作呼び出しと操作呼び出しを別々に操作します。レシーバは、目的2に明示的に必要です。

作成直後に起動した場合、またはレシーバが呼び出し元の役割を果たしている場合は、単独目的のスタンドアロンの起動者はありません。実行者がいないということは、実際には哲学的な質問であるかどうか:

このように見てください:あなたは作成、スケジューリング、呼び出しを分離します。それは3つの別々のクラスとしてそれらを実装しなければならないというわけではありません。これは、コマンドパターンのライフサイクルに関わる論理的な役割です。

編集:私は、あなたがそれらを分けなければならないと主張する単一の責任原則を推測しますが、commen senseのようなものがあります:)ローカル条件が観察されることがあります。

1

私が知っているように、java.lang.Runnableは、Threadクラスが呼び出し側として動作するコマンドパターンの例の1つです。 RunnableクラスのオブジェクトをThreadクラスに渡し、start/runを呼び出します。

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

したがって、呼び出し元はオプションではありませんが、クライアントに密接に結合されていません。したがって、コマンドパターンのUMLは、クライアントクラスと呼び出し元クラスの間にいかなる関係も表示しません。

この質問に関連する別のanswer

関連する問題