정책에 대한 전략 및 전략에 대한 정책

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과 같은 일등석 시민으로 기능을 취급하는 언어입니다. .

그 말 :

• 컴파일 시간에 결정되는 정책은 일반적으로 이진 별 응용 프로그램 논리를 원하는 특별한 상황에만 유용합니다. 예를 들어 웹 인터페이스를 통해 또는 직접 손으로 각 고객마다 약간 사용자 정의 된 소프트웨어를 개발할 수 있습니다. 이는 정책 기반 패턴 일 것입니다.

• 전략은 런타임에 결정되며 실제로 즉시 변경할 수 있습니다. 예를 들어, 지원 그룹보다 Salesforce에 대한 다른 사용자 인터페이스 및 논리를 구현하는 소프트웨어가있을 수 있지만, 모두 동일한 고객 및 라이센스 정보를 처리해야하므로 별도로 유지 관리 된 앱을 갖지 않고 단순히 하나의 앱이있는 앱이있는 것이 아니라 인터페이스가 필요에 따라 변경됩니다.

-아담

Answer 2

나는 그들이 같은 것.