战略对政策和政策对战略
A Strategy against Policy and a Policy against Strategy
当我第一次发现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_; };
随之而来的是Policy模式,它将允许我在向包含类提供参数方面有更大的灵活性——整个类,按照我喜欢的方式进行配置,尽管是动态交换行为。。。这并不太容易(除非政策的一部分是制定战略!)。
class MyMonsterTrait { typedef typename ElveAI AI; };
template< class MonsterTrait >
class Monster : public MonsterTrait::AI
{
void idle (void) { attack(); }
};
这两种模式对我来说似乎都很强大,我喜欢在不同的情况下使用这两种。但我不确定在某些情况下是否有特定/典型/更实际的应用。
我想知道:你在哪里使用策略,在哪里使用政策?哪一个更合适
策略主要在编译时设置,而策略则在运行时设置。此外,策略通常是C++概念,仅适用于少数其他语言(例如D),而策略模式可用于许多(大多数?)面向对象的语言,以及将函数视为第一类公民的语言,如python。
话虽如此:
-
在编译时确定的策略通常只适用于需要在每个二进制基础上使用不同应用程序逻辑的特殊情况。例如,您可能会为每个客户开发稍微定制的软件,无论是通过web界面还是手动,这都是一种基于策略的模式。
-
策略是在运行时确定的,实际上可以随时更改。例如,你可能有一个软件,它为销售人员和支持小组实现了不同的用户界面和逻辑,但他们都必须处理相同的客户和许可信息,所以你不需要两个单独维护的应用程序,只需要一个应用程序的界面根据需要进行更改。
-Adam
我以为它们是一样的东西。
相关文章:
- 没有找到相关文章