从零开始学设计模式———策略模式

从零开始学设计模式———策略模式

策略模式也是一种”组件协作模式“，通过晚期绑定来实现框架与应用的松耦合，是二者协作时常用的模式。
典型的”组件协作模式“有：

	模板方法模式
	策略模式
	观察者模式

动机

在软件过程中，某些对象使用的算法多种多样，经常改变，如果将这些算法都编码到对象中，会使对象变的异常复杂，有时候支持不使用的算法也是一个性能负担。

如何在运行是根据需要透明的更改对象算法？将算法与对象本身解耦，从而避免上述问题？

如下算多国税的代码：

enum TaxBase{
	CN_Tax，
	US_Tax，
	DE_Tax
};

class SalesOrder{
	TaxBase tax;
public:
	double CalulaterTax(){
		//...
		if(tax == CN_Tax){
			//CN**************
		}
		else if(tax == US_Tax){
			//US**************
		}
		else if(tax == DE_Tax){
			//DE**************
		}
		//...
	}
}

上面代码如果需要支持FR国家的税计算，该怎么办呢？有人可能会如下更改

enum TaxBase{
	CN_Tax，
	US_Tax，
	DE_Tax，
	FR_Tax  //更改
};

class SalesOrder{
	TaxBase tax;
public:
	double CalulaterTax(){
		//...
		if(tax == CN_Tax){
			//CN**************
		}
		else if(tax == US_Tax){
			//US**************
		}
		else if(tax == DE_Tax){
			//DE**************
		}
		else if(tax == FR_Tax){ //更改
			//...
		}
		//...
	}
}

可以发现上面的更改代码违反了设计的开闭原则，类模块应该尽可能的用扩展的方式去支持未来的变化，而不是直接通过修改源代码的方式去支持变化。如何通过扩展的方式去解决上面的问题呢？

如果换成如下的代码实现：

class TaxStrategy{
public:
	virtual double Calculate(const Context& context)=0
	virtual ~TaxStrategy(){}
};

class CNTax : public TaxStrategy{
public:
	virtual double Calculate(Context& context){
		//**********
	}
};

class USTax : public TaxStrategy{
public:
	virtual double Calculate(Context& context){
		//**********
	}
};

class DETax : public TaxStrategy{
public:
	virtual double Calculate(Context& context){
		//**********
	}
};

class SalesOrder{
private:
	TaxStrategy* strategy;
public:
	//工厂
	SalesOrder(StrategyFactory* strategyFactory){
		this->strategy = strategyFactory->NewStrategy();
	}
	~SalesOrder(){
		delete this->strategy
	}
	public double CalculateTax(){
		//...
		Context context();
		double val = 
			strategy->Calculate(context);
		//...
	}
}

上面的代码通过虚函数，子类通过重载父类的虚函数达到扩展的目的。如果要添加FR国家的税计算业务只需要扩展代码，添加子类：

//扩展
class FRTax : public TaxStrategy{
public:
	virtual double Calculate(Context& context){
		//**********
	}
};

其中SalesOrder类完全不用更改，通过扩展的方式达到目的，遵循了设计开放封闭原则。

策略模式定义

定义一系列算法，把它们一个个封装起来，并且使它们可互相替换（变化）。该模式使得算法可独立于使用它的客户程序（稳定）而变化（扩展，子类化）。—GOF

结构

这个模式涉及到三个角色：

●　　环境(Context)角色：持有一个Strategy的引用。

●　　抽象策略(Strategy)角色：这是一个抽象角色，通常由一个接口或抽象类实现。此角色给出所有的具体策略类所需的接口。

●　　具体策略(ConcreteStrategy)角色：包装了相关的算法或行为。

总结

1. Stategy及其子类为组件提供了一系列可重用的算法，从而可以使得类型在运行时方便的根据需要在各个算法之间切换。
2. Stategy模式提供了用条件判断语句以外的另一种选择，消除条件判断语句，就是在解耦合。包含有许多条件判断语句的代码通常都需要Stategy模式。
3. 如果Stategy对象没有实例变量，那么各个上下文可以共享同一个Stategy对象，从而节省对象开销。