2

システムにコマンド パターンを実装しました。これは主に、いくつかの層があり、ロジックをリモートで「呼び出す」必要があるためです。

class DoWorkCommandMessage { int param; }

class DoWorkCommandHandler : Handler<DoWorkCommandMessage>
{
    Execute(MyObject object) {
       object.DoWork(message.param);
    }
}

class MyObject
{
    void DoWork(int param) {
        _proxy.SendMessage(new DoWorkBinaryMessage(param));
    }
}

ご覧のとおり、私は基本的にメッセージを取得してメソッド呼び出しに変換し、それを別の層に送信されるメッセージに変換しています。

ここに何か問題があるように感じます。

最終的に MyObject をリファクタリングしてすべてのメソッドを削除し、メッセージを受け取って翻訳し、ディスパッチする単純な ProcessMessage メソッドに置き換えました。

これは、MyObject が「オブジェクト」ではなく、ほとんど単なる変換コードになったことを除けば問題ありませんでした...

単体テストを行うには、単純なメソッド呼び出しを行うのではなく、ProcessMessage() を呼び出し続ける必要があります。

「メッセージングと変換」対「メッセージ - >メソッド - >メッセージ」アプローチの間のこの戦いについての考えを探しています。明らかに、メッセージとメソッドは非常に密接に関連しています。

4

1 に答える 1

1

混乱や困難は、実際にコマンド パターンを使用していないことだと思います。あなたはそれをメッセージングと混ぜます。これは Command... の名前でもわかりますDoWorkCommandMessage。古典的な Command パターンでは、作業は実際には Command オブジェクトによって行われます。メッセージング アプローチでは、メッセージは DTO として渡され、ハンドラーによって実行されます。

さらに説明するために、使用するアプリケーションがあります

AbstractCommand
+ Execute()
+ CanUndo()
+ Undo()
+ CanChain(cmd)
+ Chain(cmd)

そのクラスの具体的なインスタンスは次のとおりです。

MoveUnitCommand  // a unit is a graphic piece on a game board
+ UnitId
+ Destination
+ Execute()
  {
      units = Units.Find(UnitId)
      prevCoords = units.Position
      units.Position = Destination
  }
+ CanUndo() { return true; }
+ Undo()
  {
      units = Units.Find(UnitId)
      units.Position = prevCoords 
  }
+ etc, etc

コマンド サブクラスは、何をすべきかを説明するだけでなく、実際にシステムの状態に作用することに注意してください。

于 2011-12-15T13:46:15.467 に答える