设计模式：Strategy（策略）模式

Strategy模式：策略模式。

模式概述：

定义一系列的算法，把他们一个个封装起来，并且使它们可以相互替换，Strategy模式使算法可以独立于使用它的客户而改变。在软件开发过程中，会遇到实现某一个功能有多种算法或者策略。我们可以根据不同的环境来选择不同的算法或者策略。如果我们统一的将这些算法的实现集成在同一个方法（函数中），可能需要用到较多的if...else...。或者我们将其集成在同一个类中，每一个方法代表一个策略或者方法。但这两种方法在算法或者策略不多时，还体现不出什么，但是当较多时，那么使用if...else 会造成代码的冗余；如果集成在同一个类中，那么在客户端代码的维护就回十分的困难。这个时候，Strategy模式的好处就体现出来了。

Strategy模式关键特征：

意图：可以根据上下文，可以使用不同的业务规则或算法。

问题：对所需算法的选择取决鳄鱼发出请求的客户或者需要处理的数据。如果只有一些不会变化的算法，就不需要Stategy模式。

解决方案：将对算法的选择和算法的实现相分离，允许根据上下文进行选择。

模式的组成：

Strategy指定了如何使用不同的算法；各concreteStrategy实现了这些不同的算法；Context通过类型为Strategy的引用使用具体的ConcreteStrategy,Strategy与Context相互作用以实现所选算法。Context将来自客户端的请求转发给Strategy。

图示：

代码实现：

Strategy.h

#include <iostream>
using namespace std;


class Strategy
{
public:
	Strategy();
	virtual~Strategy();
	virtual void Algorithm() = 0;
};


class ConcreteStrategyA:public Strategy  //A策略
{
public:
	ConcreteStrategyA();
	~ConcreteStrategyA();
	void Algorithm();
};
class ConcreteStrategyB :public Strategy  //B策略
{
public:
	ConcreteStrategyB();
	~ConcreteStrategyB();
	void Algorithm();
};


class Context
{
public:
	Context();
	~Context();
	Context(Strategy* strategy);

	void Call();
private:
	Strategy* m_Strategy;
};

Strategy.cpp

#include "Strategy.h"
#include <iostream>
using namespace std;

Context::Context()
{
}
Context::Context(Strategy* strategy) :m_Strategy(strategy)
{
}

Context::~Context()
{
}

void Context::Call()
{
	m_Strategy->Algorithm();
}
Strategy::Strategy()
{
}

Strategy::~Strategy()
{
}

ConcreteStrategyA::ConcreteStrategyA()
{
}

ConcreteStrategyA::~ConcreteStrategyA()
{
}

void ConcreteStrategyA::Algorithm()
{
	cout << "A 策略" << endl;
}
ConcreteStrategyB::ConcreteStrategyB()
{
}

ConcreteStrategyB::~ConcreteStrategyB()
{
}

void ConcreteStrategyB::Algorithm()
{
	cout << "B 策略" << endl;
}

Main.cpp

#include "Strategy.h"
#include <iostream>
using namespace std;

int main()
{
	Context *pContextA = new Context(new ConcreteStrategyA());
	pContextA->Call();

	Context *pContextB = new Context(new ConcreteStrategyB());
	pContextB->Call();

	return 0;
	
}

Strategy模式优点：

1) 相关算法系列 Strategy类层次为Context定义了一系列的可供重用的算法或行为。 继承有助于析取出这些算法中的公共功能。

2) 提供了可以替换继承关系的办法： 继承提供了另一种支持多种算法或行为的方法。你可以直接生成一个Context类的子类，从而给它以不同的行为。但这会将行为硬行编制到

 Context中，而将算法的实现与Context的实现混合起来,从而使Context难以理解、难以维护和难以扩展，而且还不能动态地改变算法。最后你得到一堆相关的类 , 它们之间的唯

一差别是它们所使用的算法或行为。 将算法封装在独立的Strategy类中使得你可以独立于其Context改变它，使它易于切换、易于理解、易于扩展。

3) 消除了一些if else条件语句 ：Strategy模式提供了用条件语句选择所需的行为以外的另一种选择。当不同的行为堆砌在一个类中时 ,很难避免使用条件语句来选择合适的行

为。将行为封装在一个个独立的Strategy类中消除了这些条件语句。含有许多条件语句的代码通常意味着需要使用Strategy模式。

4) 实现的选择 Strategy模式可以提供相同行为的不同实现。客户可以根据不同时间 /空间权衡取舍要求从不同策略中进行选择。

Strategy模式缺点:

1)客户端必须知道所有的策略类，并自行决定使用哪一个策略类:  本模式有一个潜在的缺点，就是一个客户要选择一个合适的Strategy就必须知道这些Strategy到底有何不同。此

时可能不得不向客户暴露具体的实现问题。因此仅当这些不同行为变体与客户相关的行为时 , 才需要使用Strategy模式。

2 ) Strategy和Context之间的通信开销 ：无论各个ConcreteStrategy实现的算法是简单还是复杂, 它们都共享Strategy定义的接口。因此很可能某些 ConcreteStrategy不会都用到

所有通过这个接口传递给它们的信息；简单的 ConcreteStrategy可能不使用其中的任何信息！这就意味着有时Context会创建和初始化一些永远不会用到的参数。如果存在这样

问题 , 那么将需要在Strategy和Context之间更进行紧密的耦合。

3 )策略模式将造成产生很多策略类：可以通过使用享元模式在一定程度上减少对象的数量。 增加了对象的数目 Strategy增加了一个应用中的对象的数目。有时你可以将

 Strategy实现为可供各Context共享的无状态的对象来减少这一开销。任何其余的状态都由 Context维护。Context在每一次对Strategy对象的请求中都将这个状态传递过去。共享

的 Strategy不应在各次调用之间维护状态。

总结：

Strategy模式以下列几条原则为基础：

1.对象都是具有职责的

2.这些职责不同的具体实现是通过多态的使用完成的。

3.概念上想同的算法具有多个不同的实现，需要进行管理。

将问题域中的各个行为互相分离开来，也就是将它们解耦，是一个好的设计实践，这使我们可以修改负责某一行为的类，不会对其他类产生不良影响。