反对政策和反对战略政策的战略 [英] A Strategy against Policy and a Policy against 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（）; } 
}; 
  

这两种模式对我来说都是非常强大的，我喜欢在不同的情况下使用。但我不确定在某些情况下是否有特定/典型/更实用的应用程序。

我想知道：和哪里的政策？

解决方案

策略在很大程度上是在编译时设置的，而策略是在运行时设置的。此外，策略通常是C ++概念，并且仅适用于少数其他语言（例如D），而策略模式可用于许多（最多）面向对象的语言，以及将函数作为一等公民处理的语言，如python

这就是说：

• 在编译时，通常只对特殊情况有用，其中您希望基于每个二进制的不同的应用程序逻辑。例如，您可以通过Web界面或手动为每个客户开发稍微定制的软件，这将是一种基于策略的模式。




• 一个策略在运行时确定，事实上可以在运行中改变。例如，你可能有一个软件实现了不同的用户界面和逻辑为salesforce比支持组，但他们都必须处理相同的客户和许可信息，因此，而不是有两个单独维护的应用程序，你只有一个应用程序

  
  
  $ b

  When I first discovered the Strategy pattern, I was amazed of the seemingly endless possibilities it offered to me and my programs. I could better encapsulate my models' behaviour and even exchange this behaviour on the fly. But the strategy could also be used to to provide traits and payload to the containing object - data that was declared in a superclass. Life was fine.

  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_; };
  

  And along came the Policy pattern and it would allow me even greater flexibility in supplying parameters to a containing class - whole classes, outfitted however I liked, albeit dynamically exchanging the behaviour... that was not too easy (unless part of the policy was to have a strategy!).

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

  Both patterns seem to be very powerful to me and I like to use both, in different circumstances. But I'm not sure if there are particular/typical/more-practical applications for either at some situations.

  I am wondering: where do you use strategies and where policies? Where are either better suited?

  解决方案

  Policies are largely set at compile time, while strategies are set at runtime. Further, policies are generally a C++ concept, and apply only to a minority of other languages(for example D), while strategy pattern is available to many (most?) object oriented languages, and languages that treat functions as first class citizens like python.

  That being said:

  • A policy, being determined at compile time, is generally only useful for special situations where you want different application logic on a per-binary basis. For instance you might develop software that is slightly customized for each customer, whether via a web interface, or by hand, this would be a policy-based pattern.

  • A strategy is determined at runtime, and in fact can be changed on the fly. For instance you might have software which implements a different user interface and logic for the salesforce than for the support group, but they all have to deal with the same customer and licensing info so rather than having two separately maintained apps you simply have one app whose interface changes as needed.

  -Adam

  这篇关于反对政策和反对战略政策的战略的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！