[解決済み] ストラテジーパターンとコマンドパターンの使い分け

質問

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

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

1つのパターンと他のパターンのどちらを使用するかは、どのように決定するのでしょうか？

どのように解決するのですか？

この 2 つのパターンの違いを説明するために、GoF デザイン パターンのいくつかのカプセル化階層テーブルを含めています。うまくいけば、それぞれがカプセル化するものをよりよく示すことができ、私の説明がより意味をなすようになります。

まず最初に、階層は、与えられたパターンが適用される範囲、またはテーブルのどちら側から始めるかによって、あるレベルの詳細をカプセル化するために使用する適切なパターンを一覧表示します。

表からわかるように、Strategy Patternオブジェクトはアルゴリズムの実装の詳細を隠すので、異なるStrategyオブジェクトを使用すると、同じ機能を異なる方法で実行することになります。各ストラテジーオブジェクトは特定の要因に最適化されているか、他のパラメータで動作している可能性があります。

Commandパターンはアルゴリズムよりもはるかに小さなレベルの詳細をカプセル化する。オブジェクトにメッセージを送るために必要な詳細、つまりレシーバ、セレクタ、引数をカプセル化します。プロセス実行のそのような小さな部分をオブジェクト化することの利点は、そのようなメッセージは、その詳細をハードコードすることなく、一般的な方法で時間や場所の異なるポイントに沿って呼び出すことができるということです。これにより、実行前に特定の呼び出しの詳細を知る必要がなく、メッセージを 1 回以上呼び出したり、システムの異なる部分や複数のシステムに伝えたりすることができます。

デザインパターンにありがちなことですが、パターン名を冠するために、すべての実装が細部まで同一である必要はありません。詳細は、実装や、オブジェクト対メソッドの引数としてどのようなデータがエンコードされているかで変わる可能性があります。