問題タブ [command-pattern]

ビジターがレシーバーの状態を変更できるようにすることは一般的に受け入れられますか、それとも代わりにコマンドパターンにする必要がありますか？

わかりました、これはちょっとばかげています。MVC とコマンド パターンの使用について頭を悩ませようとしています。質問は基本的に、コードを配置する場所に関するものです。

MVC パターンでは、コマンドはどこでインスタンス化されますか? それらはコントローラによって作成されたのか、モデルに完全に含まれているのか、どちらでもないのか。

ところで、元に戻す/やり直す必要がない場合は、コマンドパターンを使用する必要があります。

よろしく

このビデオ[@ 7:50] によると、Google はリクエスト処理 API の上にコマンド パターンを使用することを推奨しています。そのパターンを実装する便利なプロジェクトgwt-dispatchもあります。

gwt-dispatch のドキュメントによると、コマンドごとに 4 つのクラスを作成する必要があります。

• アクション (コマンドなど)
• 結果 (例: 応答)
• アクションハンドラー
• モジュール

私のサービス API には 8 つの BSO にまたがる 100 のメソッドがあると仮定します。400 近くの新しいクラスを作成する理由を誰か説明してもらえますか? このパターンはどのような素晴らしさを買いますか?

私が達成しようとしているのは、永続ストレージ（データベース）に「元に戻せない」変更の永続リストを作成することです。

このアーキテクチャでは、ドメインオブジェクトとトランザクションの作業単位、およびコマンドパターンを使用することを考えた最後の部分（元に戻る）にリポジトリを使用しています。しかし、私にとっては、実行されたコマンドを永続化するための良い解決策はないようです。

基本的に、リポジトリの追加/更新/削除には3つの書き込み操作があり、コマンドパターンを使用すると、コマンドが実行される前の状態を保存する必要があります。例：ドメインオブジェクト（エンティティ）を削除する前に保存して、コマンドでundoが呼び出されたら復元できるようにする必要があります。ここでの大きな問題は、前の状態をきちんと保存する方法です！

たぶんあなたたちの誰かが同じ質問に出くわしましたが、私の心の中ではそれほど珍しいことではありません。

ありがとう、クリス

wpfコンテキストに2つのメニュー項目があります。それらをコマンドでバインドします。両方の項目が使用できない場合、つまり両方のコマンドを実行できない場合、コンテキストメニューを非表示にするにはどうすればよいですか？

すべてのコマンドが次のパターンに従う Winforms UI を実装しているとします。

このようなコマンドをトリガーするボタンまたはメニュー項目には、次の設定が必要です。

• プロパティEnabledはコマンドのCanExecute
• イベントClickはコマンドにリンクされますExecute(メソッド シグネチャが異なるため、中間イベント ハンドラーを介して)

問題CanExecuteINotifyPropertyChangedは、このプロパティを直接変更することはできず、コマンドに関連する必要のないプログラム内の他の要因に依存するため、ここでは機能しないための実装です。PropertyChangedまた、プログラムのまったく無関係な部分でコマンドのイベントをトリガーする必要はありません。

が変更されたことをデータ バインディング マネージャーにどのように通知しますCanExecuteか?

これが私の問題の（純粋に架空の）例です：

理想的には、UI が (揮発性のフィールドであるかのように) 常にチェックするようにしたいのですCanExecuteが、これは Winforms のデータ バインディングの仕組みではありません。誰でもこの問題の解決策を持っていますか?

_{注：ところで、私はWPFを認識しています。私の質問の背景は、WPF の一般的な方向で既存の Winforms アプリケーションを徐々に改善しようとしているということです。しかし、実際にWPFを使用して、私が尋ねた問題を取り除くことは、今のところ実現不可能です。}

よく知られている Command パターンは、元に戻す/やり直し機能を備えたモデルを実装する場合によく使用されます。元に戻す/やり直しを実装する単純な Delphi フォームの参照実装 (例) を探しています。

私が見た限りでは、3 つの編集ボックス、6 つのメモ ボックス、およびいくつかのコンボ ボックスとその他の単純な編集コントロールを備えた単純な Delphi データ入力フォームは、通常、元に戻す/やり直しをサポートしていません。

別の Delphi ビュー (フォーム) とモデル オブジェクト (データ オブジェクトはフォームへのすべての編集と同期して更新される検証および制御ロジックは、フォームやモデルに組み込まれるのではなく、分離されます。

MVC を使用する必要がなく、モデル オブジェクトやコントローラー オブジェクトを持たない Delphi デモ アプリのプロトタイプを作成するだけでよい場合、純粋で単純な Delphi の元に戻す/やり直しは「1 つのフォームが私のもの」 -app" の方が設計は簡単ですが、オブジェクトを記録して再生し、それらを TEdit.OnChange などの Delphi フォーム アクションに同期する必要があるため、より複雑になります。

コマンドパターンの例をたくさん見てきました

しかし、それらはすべてデスクトップアプリケーションのコンテキストにある傾向があります。

つまり、「コマンドは、操作を呼び出すオブジェクトを、その実行方法を知っているオブジェクトから切り離します」

純粋なHTML（ただしZend Framework MVC駆動）Webサイトのコンテキストでは、現在のページを更新して特定のコマンドを呼び出すユーザーの「リンクをクリック」を考えています。ユーザーがサイトのどのページにいるかは関係ありません。

例として、ブログアプリでは次のようになります。

すなわち

両方で「ブログ投稿を削除」などのHTMLフォームボタンを表示できるようにするには、次のようにします。

• 「リストページ」（ブログ投稿を一覧表示）

• 「ページの編集」（ブログ投稿の編集）

• 「リストページ」のフォームアクションは「リストページ」を指します

• 「ページの編集」のフォームアクションは「ページの編集」を指します

ZFMVCのコントローラー部分は一種のコマンドパターンだと思います。ただし、これはURLを特定のコントローラーにルーティングします。また、コマンドアクションを特定のコマンドレシーバーに同時にルーティングしようとしています。

コマンドパターンはここに適用されますか、それともデスクトップアプリやAJAX対応サイトなどの豊富なグラフィカルユーザーインターフェイスのコンテキストでのみ本当に役立ちますか？

どちらの設計パターンもアルゴリズムをカプセル化し、実装の詳細を呼び出しクラスから分離します。私が認識できる唯一の違いは、Strategy パターンは実行用のパラメーターを受け取るのに対し、Command パターンはそうしないことです。

コマンドパターンは、作成時に実行のためのすべての情報が利用可能である必要があり、その呼び出しを遅らせることができるようです (おそらくスクリプトの一部として)。

どちらのパターンを使用するかの判断基準は何ですか?

アクション デリゲートのキューを使用して GOF コマンド パターンを実装することは可能ですか?

しばらくの間、頭を抱えようとしてきましたが、キューに追加したい可能なアクションのそれぞれにさまざまな数のパラメーターがある可能性があるため、困惑しています。

助言がありますか？コマンド パターンに注目して間違ったツリーを鳴らしていませんか?

アップデート：

jgauffinに感謝します。うまくいきます...私の実装は次のようになります