2

こんばんは。コマンドパターンを読んでいて、それが私が構築したいものに適しているかどうか疑問に思っています。

基本的に、サーバーとのソケット接続を形成するクライアントがあります。私のサーバーには、クライアントがメソッドを呼び出す必要があるクラス「foo」が1つあります。

foo には、クライアントが呼び出す 5 つのメソッドがあるとします。サーバー上でデマーシャリングされたオブジェクトをマーシャリングするという過ちを過去に犯しました。次に、オブジェクト内の変数をチェックし、switch ステートメントを使用して、サーバー ロジックはどのアクションを呼び出す必要があるかを判断できます。

これを避けたいので、コマンドパターンが役立つと思います。しかし、サーバー上の「foo」クラスの例では、foo で呼び出されるメソッドごとにコマンド クラスを作成する必要がありますか? クライアントからサーバーに送信されるクラスはコマンド クラスである必要がありますか? この場合、必要な受信機は 1 つだけですか? - foo クラス?

'foo' クラス名について申し訳ありません。具体的なクラス名はまだありません!

よろしくお願いします

4

1 に答える 1

4

何をしても、その switch() ステートメントを完全に取り除くことはできません。コマンドパターンは、次のことを提案します： 

abstract class AbstractCommand() {
  abstract void execute();
}
class ConcreteCommand extends AbstractCommand {
  // execute implementation
}
// more command classes as needed; probably one per each of your method calls

次に、コマンド ファクトリがあります。

class CommandFactory {
  AbstractCommand createCommandForMessage(Message m) {
    // ... switch() goes here
  }
}

メッセージ受信部分は次のように単純になります。

public class MessageReceiver {
  public void work() {
    while (true) {
      Message m = receiveMessage();
      AbstractCommand command = commandFactory.createCommandForMessage(m);
      command.execute();
    }
  }
}

これの良いところは、コマンドの実際のロジック (execute() メソッドの実装) を、使用するコマンドを決定するロジック、ネットワーク上でメッセージを受信する方法を知るロジックから明確に分離できることです。

于 2011-02-15T23:14:45.390 に答える