strategy(策略)—对象行为模型

strategy(策略)—对象行为模型
1. 意图
定义一系列的算法，把他们一个个封装起来，并且使它们可相互替换。本模式使得算法
可独立于使用它的客户而变化。
2. 别名
政策(Policy)
3. 动机
有许多算法可对一个正文流进行分行。将这些算法硬编进使用它们的类中是不可取的，
其原因如下：
① 需要换行功能的客户程序如果直接包含换行算法代码的话会变得复杂，这使得客户程序庞大并且难以维护，尤其当其需要支持多种换行算法时问题会更严重；
② 不同的时候需要不同的算法，我们不想支持我们并不使用的换行算法；
③ 当换行功能是客户程序的一个难以分割时，增加新的换行算法或改变现有算法将十分困难。
我们可以定义一些类来封装不同的换行算法，从而避免这些问题。一个以这种方法封装的算法称为一个策略(strategy),如下图所示。

假设一个Composition类负责维护和更新一个正文浏览程序中显示的正文换行。换行策略不是Composition类实现的，而是有抽象Compositor类的子类各自独立地实现的。
Composition维护对Compositor对象的一个引用。一旦Composition重新格式化它的正文，它就将这个职责转发给它的Compositor对象。Composition的客户指定应该使用哪一种Compositor的方式是直接将它想要的Compositor装入Composition中。
4. 适用性
当存在以下情况时使用strategy模式
① 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为配置一个类的方法；
② 需要使用一个算法的不同实体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式；
③ 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构；
④ 一个类定义了多种行为，并且这些行为在这个类的操作中以许多条件语句的形式出现。将相关的条件分支移入它们各自的strategy类中以代替这些条件语句。
5. 结构

6. 协作
Strategy和Context相互作用以实现选定的算法。当算法被调用时，Context可以将该算
法所需要的所有数据都传递给该Strategy。或者，Context可以将自身作为一个参数传递给strategy操作。这就让Strategy在需要时可以回调Context；
Context将它的客户请求转发给他的Strategy。客户通常创建并传递一个ConcreteStrategy对象给该Context；这样，客户仅与Context交互。通常有一系列的ConcreteStrategy类可供客户从中选择。
7. 效果
Strategy模式有下面的一些优点和缺点：
⑴相关算法系列；
⑵一个替代继承的方法；
⑶消除了一些语句 Strategy模式提供了用条件语句选择所需的行为以外的另一种选
择。当不同的行为堆砌在一个类中时，很难避免使用条件语句来选择合适的行为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。
例如，不用Strategy，正文换行的代码可能是象下面这样
void Composition::Repair () {
switch (_breakingStrategy) {
case SimpleStrategy:
ComposeWithSimpleCompositor();
break;
case TeXStrategy:
ComposeWithTeXCompositor();
break;
// ...
}
// merge results with existing composition, if necessary
}
Strategy模式将换行的任务委托给一个Strategy对象从而消除了这些case语句：
void Composition::Repair () {
_compositor->Compose();
// merge results with existing composition, if necessary
}
含有许多条件语句的代码通常意味着需要使用Strategy模式。
⑷实现的选择
⑸客户必须了解不同的Strategy 本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时，才需要使用Strategy模式。
⑹Strategy和Context之间的通信开销
⑺增加了对象的数目 Strategy增加了一个应用中的对象的数目。有时你可以将Strategy实现可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享的Strategy不应在各次调用之间维护状态。
8. 实现
考虑下面的实现问题：
⑴ 定义Strategy和Context接口 Strategy和Context接口必须使得ContextStrategy能够
有效的访问它所需要的Context中的任何数据，反之亦然。一种办法是让Context将数据放在参数中传递给Strategy操作——也就是说，将数据发送给Strategy。这使得Strategy和Context解耦。但另一方面，Context可能发送一些Strategy不需要的数据。
例子：
#include <vector>
#include <algorithm>
#include <time.h>
using namespace std;

template <typename T>
class SortStrategy
{
public:
virtual void Sort(vector<T>& v) = 0;
};
template <typename T>
class SortQuick : public SortStrategy<T> // ConcreateStrategy1
{
public:
void Sort(vector<T>& v)
{
std::sort(v.begin(), v.end());
}
};

template <typename T>
class SortStable : public SortStrategy<T> // ConcreateStrategy1
{
public:
void sort(vector<T> & v)
{
std::stable_sort(v.begin(), v.end());
}
};

template <typename T>
class Context { // Context, who or whose client takes charge of which strategy will be selected
public:
Context()
{
m_pStrategy = NULL;
}
virtual ~Context()
{
if(m_pStrategy != NULL)
delete m_pStrategy;
}
void SetStrategy( SortStrategy<T>* pStrategy);
void ReadVector( vector<T> &v_t);
bool SortVector();
void OutputVector();
private:
vector<T> m_vt;
SortStrategy<T>* m_pStrategy; // a pointer to current strategy
};

template <typename T>
void Context<T>::SetStrategy( SortStrategy<T>* pStrategy )
{
if ( NULL != m_pStrategy )
delete m_pStrategy;

m_pStrategy = pStrategy;
}

template <typename T>
void Context<T>::ReadVector( vector<T>& v_t)
{
m_vt.clear();
copy( v_t.begin(), v_t.end(), back_inserter(m_vt));
}

template <typename T>
bool Context<T>::SortVector()
{
if ( NULL == m_pStrategy )
return false;

m_pStrategy->Sort( m_vt );

return true;
}

template <typename T>
void Context<T>::OutputVector()
{
copy( m_vt.begin(), m_vt.end(), ostream_iterator<T>( cout, " " ) );
}

// a functor to generate random int
struct RandGen
{
RandGen(int ratio) { m_ratio = ratio; }
int operator() () { return rand() % m_ratio + 1; }
private:
int m_ratio;
};

int main()
{
const int NUM = 9;
vector< int > vi;
time_t t;
srand( (unsigned) time(&t) );

// create a vector with random information
vi.reserve(NUM + 1);
generate_n(back_inserter(vi), NUM, RandGen(NUM));

Context< int > con;
con.SetStrategy( new SortQuick<int>() );
con.ReadVector( vi );
con.OutputVector();

cout << endl;
con.SortVector();
con.OutputVector();

return 0;
}

另一种办法是让Context将自身作为一个参数传递给Strategy，该Strategy再显式地向该Context请求数据。或者，Strategy可以存储对它的Context的一个引用，这样根本不在需要传递任何东西。这两种情况下，Strategy都可以请求到它所需要的数据。但现在Context必须对它的数据定义一个更为精细的接口，这将Strategy和Context更紧密耦合在一起。
⑵将Strategy作为模板参数 在C++中，可利用模板机制用一个Strategy来配置一个类。然而这种技术仅当下面条件满足时才可以使用①可以在编译时选择Strategy②它不需在运行时改变。在这种情况下，要被配置的类被定义为一个Strategy类作为一个参数的模板类：
template <class AStrategy>
class Context {
void Operation() { theStrategy.DoAlgorithm(); }
// ...
private:
AStrategy theStrategy;
};
当它被实例化时该类用一个Strategy类来配置：
class MyStrategy {
public:
void DoAlgorithm();
};
Context<MyStrategy> aContext;
使用模板不再需要定义给Strategy定义接口的抽象类。把Strategy作为一个模板参数使得可以将一个Strategy和它的Context静态地绑定在一起，从而提高效率。
⑶使Strategy对象成为可选的 如果即使在不使用额外的Strategy对象的情况下，Context也还有意义的话，那么它还可以被简化。Context在访问某Strategy前先检查它是否存在，如果有，那么就使用它；如果没有，那么Context执行缺省的行为。这种方法的好处是客户根本不需要处理Strategy对象，除非它们不喜欢缺省的行为。
9. Strategy和State的异同
从结构上看，Strategy模式与上一篇讨论的State模式有几分相似，但二者所讨论的Context（情景）具有显著的差异：
State模式在于将其状态信息分离出来保存到一个独立的对象中，以便状态信息的获取或状态的转换；Strategy模式在于将可能的算法分离出来，根据需要进行适当的选择。此外，二者的区别还在于，Strategy模式中各个Strategy（算法、策略）往往用于解决相同的问题，即只是解决同一问题的不同“策略”、“途径”，而且，一次只能有一个Strategy为上次应用提供服务；而State模式中的各个State本身往往具有一定的差异，但他们之间存在明显的相互转换的关系，而且这种转换往往会在程序运行过程中经常性地发生，同时存在一个以上State也是可能的。
区别参考：二者的应用场合不同。状态模式用于处理对象有不同状态（状态机）的场合，策略模式用于随不同外部环境采取不同行为的场合。在状态模式中，状态的变迁是由对象的内部条件决定，外界只需关心其接口，不必关心其状态对象的创建和转化；而策略模式里，采取何种策略由外部条件决定。所以，有人说“状态模式是完全封装且自修改的策略模式”。至于Bridge，在结构上与前两者都不一样了。要说相似之处，就是三者都有具有对外接口统一的类，展现出多态性而已。

这里还有两篇不错的有关Strategy的文章：
1.乱砍设计模式之一：STRATEGY 模式—赵子龙单骑救主
http://www.vckbase.com/document/viewdoc/?id=1633 Strategy Pattern in C++ Applications
http://www.codeproject.com/KB/architecture/strategy.aspx
2.Applying