問題タブ [command-pattern]

スタックオーバーフローで見つけることができませんでした。私はこのアプローチを思いつきました。何か良い方法があればご提案ください。
コード：

C++ クラス:

Objective C でのこのクラスの使用:

以前のプロジェクトでコマンドパターンがどのように使用されたかを見て、コマンドは異なるスレッドで実行できるため、マルチスレッド（並列）プログラミングでどのように役立つかを理解できます。コマンド間でデータを渡す必要がある場合は、データを共有メモリに格納し、そのデータへのポインタ（またはハンドル）を別のスレッドの呼び出し元に渡すことができます。

ただし、デコレータパターンには、すべてが単一のスレッドで発生する必要があるという制限があるようです。これは、デコレータがデリゲートを直接呼び出す必要があるため、同じスレッド上にある必要があることを意味します。

この制限についての私の理解は正しいですか？それどころか、複数のスレッドでデコレータを実行することは可能ですか？

私が実装しようとしているのは、データのストリームを処理するパイプラインです。

• コマンドパターンとして実装するには、そのexecuteメソッドは2つの引数を取ります。入力用のバッファーと出力用のバッファーです。
• デコレータパターンとして実装するために、そのgetdataメソッドはデリゲートを呼び出して前のステップの結果を取得し、独自の処理を適用して、結果を呼び出し元に返します。

しかし、両方のスタイルで実装した後、それぞれに元々明確ではなかった制限があることがわかりました。

• コマンドパターンを使用すると、新しいバッファーを使用してより多くの入力データの受け入れを開始できますが、以前のバッファーは、別々のワークスレッドで実行されているいくつかのコマンドによって処理されます。デコレータパターンではこれができないようです。
• デコレータパターンを使用する場合、デコレータはデリゲートに対して任意の数の呼び出しを行い、結果を1つのチャンクに結合することができます。また、1つの大きなリクエストを作成してキャッシュし、その一部を返すことで、データを分割することもできます。1つの入力バッファと1つの出力バッファでコマンドパターンを使用する場合、結果の組み合わせや分割はできません。

オブジェクト指向設計でコマンド パターンが便利な理由がわかりません。

Switchたとえば、クラスへの参照を持つコマンドを使用する代わりにLamp、抽象クラスを作成してSwitchableそのメソッドを呼び出すことはできませんか?

このようにして、インボーカーとレシーバーを分離しているので、レシーバー クラスごとに Command オブジェクトを作成する必要はありません。

初めてコマンド パターンを使用します。依存関係をどのように処理すればよいか、少しわかりません。

以下のコードでは、 をディスパッチCreateProductCommandし、後で実行するためにキューに入れます。このコマンドは、実行に必要なすべての情報をカプセル化します。

この場合、製品を作成するために何らかのタイプのデータ ストアにアクセスする必要がある可能性があります。私の質問は、この依存関係をコマンドに挿入して実行できるようにするにはどうすればよいですか?

どうもありがとう
ベン

すべてが問題になっています。なぜメニューはオブザーバーパターンではなくコマンドデザインパターンで一般的に実装されているのでしょうか。

次のシナリオがあります。

1. Edit/Employee ビューに Entity Framework エンティティ (Employee) からのモデルが取り込まれています
2. Edit/Employee から Save/Employee コントローラ アクションに投稿します。Save/Employee アクションは、プロパティとして Employee を持つ別のタイプ (EmployeeSave) を想定しています。

これは Edit/Employee メソッドです

これは、Save/Employee メソッドです。

これは EmployeeSave クラスです

MVC DefaultModelBinder は、Employee クラスと EmployeeSave クラスの両方を解決できます。

私はこのインターフェースを持っています...

実装では、2つのIDのみを検証し、有効な場合は別のインターフェイスの結果を返します...

同じビジネスドメインアセンブリでインターフェイスを定義したいのですが、2つ（またはそれ以上）のレイヤーを区別する方法を決定するのに苦労しています。論理的には、名前が同じではないにしても類似していると思うので、同じ名前空間の下に置くことはできません。名前空間を介して分離しますか？「Validation」名前空間と「Something-else」名前空間？または、すでに単語の名前を少しばかげた名前に拡張しますか...

機能を小さく、単一目的に保つにつれて、これがますます出てくるのを見ています。

アプリケーションにタスクの概念を実装する必要があります。私のプロジェクトでは、タスクは実行する必要がある操作であり、名前で識別されます。各タスクには入力パラメーター (型と値) もあり、1 つ以上の出力を生成します。

Taskクラスを実装しなければならないのですが、「なんらかの結果を伴う操作」という概念をどのように表現すればよいでしょうか? 操作の名前を文字列属性に格納することはできますが、この操作によって返される型をどのように表現すればよいでしょうか? 同様に、操作の入力パラメータのリストを実装するにはどうすればよいですか? これらのパラメータも異なるタイプである可能性があります。

目標は、Task オブジェクトをシリアル化し、別のノードに送信することです。受信者は、受信した Task オブジェクトを分析し、操作の名前を読み取り、対応する関数を実行します。

たとえば、ノード A とノード B が次のメソッドを「持っている」とします...

ノード A のサービス:

ノード B のサービス:

ノード C が長方形の面積を計算する必要がある場合、ノード A に接続し、操作 (double areaOfRectangle ) と入力 (double widthおよび double height )を指定して、ノード A にメッセージを送信する必要があることを認識します。同様に、ノード C が円の面積を計算する必要がある場合、操作と半径の長さを指定して、ノード B にメッセージを送信する必要があります。入力を送信するには、異なる型 (または新しいユーザー定義型) である可能性があるため、オブジェクトの配列を使用できます...

一部のタスクは他のタスクに依存する場合があります。つまり、入力パラメーターが別のタスクの出力を少なくとも 1 つ持つ場合があるため、タスクの出力と別のタスクの入力の間のリンクも実装する必要があります。

クラスを定義するにはどうすればよいですか?

Javaでコマンドパターンを簡単に実装しようとしていました。ただし、次のエラーが発生します。

コード：

最近、私は出会いましCommand Patternた。このパターンでは、クライアントは Reciever、ConcreteCommand、および Invoker のインスタンスを作成する責任があります。ある時点で (ボタン クリックとしましょう) Invoker の Invoke メソッドが呼び出されています。Invoke メソッドは、Reciever で特定の操作を実行する役割を担います。しかし、クライアントがレシーバーを使用して特定のアクションを直接呼び出すことができるのに、なぜインボーカー (それ以外の場合はコマンド パターン) が必要なのですか?