政策に対する戦略と戦略に対する政策

Question

最初に戦略パターンを発見したとき、それが私と私のプログラムに提供する一見無限の可能性に驚きました。モデルの振る舞いをカプセル化し、その振る舞いをその場で交換することもできます。しかし、この戦略を使用して、スーパークラスで宣言されたデータを含むオブジェクトに特性とペイロードを提供することもできます。人生は大丈夫だった。

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(); }
};

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

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

Answer 1

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

それは言われています：

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

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

-アダム

Answer 2

同じものだと思いました。