15

Strategy パターンを初めて発見したとき、私と私のプログラムに無限の可能性をもたらしてくれたことに驚きました。モデルの動作をより適切にカプセル化し、この動作をその場で交換することさえできます。しかし、この戦略を使用して、含まれているオブジェクト (スーパークラスで宣言されたデータ) に特性とペイロードを提供することもできます。人生は順調でした。

class MyMonsterAI   { float const see_radius_; virtual void attack () = 0; /* .. */ };
class ElveAI        { ElveAI() : see_radius_(150.0f) {} /* ... */ };
class CycloneAI     { CycloneAI() : see_radius_(50.0f) {} /* ... */ };
class Monster       { MyMonsterAI* ai_; };

そして、ポリシーパターンが登場し、それを含むクラスにパラメーターを提供する際の柔軟性がさらに向上しました-動作を動的に交換しますが、好きなように装備されたクラス全体...それはあまり簡単ではありませんでした(ポリシーの一部があった場合を除く)戦略を立てる!)

class MyMonsterTrait { typedef typename ElveAI AI; };

template< class MonsterTrait >
class Monster : public MonsterTrait::AI
{
    void idle (void) { attack(); }
};

どちらのパターンも私には非常に強力なように思え、さまざまな状況で両方を使用するのが好きです。しかし、状況によっては、特定の/典型的な/より実用的なアプリケーションがあるかどうかはわかりません。

私は疑問に思っています: どこで戦略を使用し、どこでポリシーを使用しますか? どこがより適していますか?

4

2 に答える 2

27

ポリシーは主にコンパイル時に設定されますが、戦略は実行時に設定されます。さらに、ポリシーは一般に C++ の概念であり、他の少数の言語 (D など) にのみ適用されますが、戦略パターンは多くの (ほとんどの?) オブジェクト指向言語、および関数を Python のようなファースト クラスの市民として扱う言語で利用できます。 .

そうは言っても:

  • コンパイル時に決定されるポリシーは、通常、バイナリごとに異なるアプリケーション ロジックが必要な特殊な状況でのみ役立ちます。たとえば、顧客ごとにわずかにカスタマイズされたソフトウェアを開発する場合があります。これは、Web インターフェースを使用するか手動で行うかを問わず、ポリシー ベースのパターンになります。

  • 戦略は実行時に決定され、実際にその場で変更できます。たとえば、Salesforce 用とサポート グループ用で異なるユーザー インターフェイスとロジックを実装するソフトウェアがあるかもしれませんが、それらはすべて同じ顧客とライセンス情報を処理する必要があるため、2 つの別々に管理されたアプリを使用するのではなく、1 つのアプリを使用するだけで済みます。インターフェイスは必要に応じて変更されます。

-アダム

于 2008-10-23T20:34:43.600 に答える
5

私はそれらが同じものだと思った。

于 2008-10-23T20:24:15.900 に答える