接上篇,本篇将会介绍C++设计模式中的Strategy 策略模式
,和上篇模板方法Template Method
一样,仍属于“组件协作”模式,它与Template Method有着异曲同工之妙。
文章目录
- 1. 动机( Motivation)
- 2. 代码演示Strategy 策略模式
- 2.1 传统方法处理
- 2.2 怎么用扩展的方式来支持未来的变化呢?- Strategy 策略模式
- 2.3 两种方法的对比分析
- 3. 模式定义
- 4. 结构( Structure)
- 5. 要点总结
- 6.其他参考博文
1. 动机( Motivation)
-
在软件构建过程中,某些对象使用的算法可能多种多样,经常改变,如果将这些算法都编码到对象中,将会使对象变得异常复杂;而且有时候支持不使用的算法也是一个性能负担。(结合下面的代码,如果算法只是在中国使用,其他国家的算法就不会被使用到,可能会占用内存资源,因此也就是一种性能负担)
-
如何在运行时根据需要透明地更改对象的算法?将算法与对象本身解耦,从而避免上述问题?
2. 代码演示Strategy 策略模式
以下是一种税的计算,比如在电子商务系统中常常需要进行订单中税的计算,假如支持跨国结算,就需要考虑不同国家税的计算方法不同。例如以下代码中中国、美国、德国之间的税率相差是很大的(初始是没有法国的),因此在代码中需要支持不同的税的计算方法。
2.1 传统方法处理
最简单的方法就是下面形式,使用枚举类型,if…else,switch…case这样的组合来支持不同的税的计算。这种形式是我们更容易想到的,初看起来也是没有问题的,但是作为面向对象设计,特别是学习过设计模式的,应该有一种思维层次,不要静态的去看一个软件的设计,而是要动态的去看。用简单话来说就是要有时间轴的概念,加上时间轴,也就是考虑问题未来的一些变化的时候,也是上面动机( Motivation)
讲到的,未来会不会有可能支持法国
,假设有这个需求的时候,就是以下完整的代码。但是这样的改动就违背了开放封闭原则
即对扩展开放,对更改封闭,类模块尽可能用扩展的方式支持未来的变化,而不是修改源代码来支持未来的变化。
enum TaxBase {CN_Tax,US_Tax,DE_Tax,FR_Tax //更改
};class SalesOrder{TaxBase tax;
public:double CalculateTax(){//...if (tax == CN_Tax){//CN***********}else if (tax == US_Tax){//US***********}else if (tax == DE_Tax){//DE***********}else if (tax == FR_Tax){ //更改//...}//....}};
2.2 怎么用扩展的方式来支持未来的变化呢?- Strategy 策略模式
以下代码不用枚举进行实现,实现了一个TaxStrategy
的基类,内部有一个Calculate
的纯虚方法,以context
作为形参取参数。对于不同的税法,将第一种方法中的一个个的算法,变成了TaxStrategy的子类。
-
SalesOrder
类中放了一个多态指针TaxStrategy* strategy
,极特殊的情况下也是可以使用引用的,但是引用还有其他毛病,一般来讲要实现多态就是需要使用指针。 -
这个指针怎么去创建呢?推荐使用后面会讲到的
工厂模式
的方式来创建,此处先做简单的了解,它不需要new一个实际对象(硬编码),而是使用外界传来的StrategyFactory
调用一个NewStrategy()
,可以返回某个国家子类的对象,具体返回哪个是由工厂决定的,不是由真正本身类决定。这个对象是在工厂内部,返回的也是一个堆对象而不是栈对象。 -
CalculateTax()
中就需要构建上下文的参数,调用double val = strategy->Calculate(context); //多态调用
,这个地方是典型的多态,可能调用某个国家的税法,依赖于NewStrategy()
返回的对象类型。
class TaxStrategy{
public:virtual double Calculate(const Context& context)=0;virtual ~TaxStrategy(){}
};class CNTax : public TaxStrategy{
public:virtual double Calculate(const Context& context){//***********}
};class USTax : public TaxStrategy{
public:virtual double Calculate(const Context& context){//***********}
};class DETax : public TaxStrategy{
public:virtual double Calculate(const Context& context){//***********}
};//扩展
//*********************************
class FRTax : public TaxStrategy{
public:virtual double Calculate(const 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); //多态调用//...}};
此处再次强调:
-
任何基类的析构函数必须是虚的,那怕是你觉得析构函数不需要写,编译器自动生成是够用的,你也应该去写一个虚的析构函数,否则多态的delete会出问题。
-
工程上不同的类是放在不同的文件中。
2.3 两种方法的对比分析
第二种方法,相对于第一种方法有什么好处呢?
只管来看,功能一样,但是要比较好处,就要放到时间轴去看,假设出现了需要支持法国的业务。
可以看到除了增加了法国的子类,SalesOrder
类中不需要做变动,而法国对象怎样被弄进来,就需要看StrategyFactory
的选择。SalesOrder
不用做变化,在面向对象设计中也就说得到了复用性,新增的法国的子类是一种扩展,这种写法遵循了开放封闭原则。
面向对象,特别是设计模式讲的复用性,指的是编译单位,也就是二进制层面的复用性
,一般认为,源代码级别,例如源码从一个地方拷贝到另一个地方,这个不叫复用,叫做粘贴源代码。真正的复用指的是你编译、测试、部署之后是原封不动,是二进制意义的单位复用,而不是源代码片段级的复用(拷贝粘贴)。
在一段代码下补一段代码,很容易打破方法前面的代码,给前面的代码引入bug,这是开发工程学中经常会出现的,因此对源代码级别的拷贝粘贴是不推荐的,而且压根不能成为复用性。
第二种下才叫做二进制意义的复用性,才满足开闭原则。
3. 模式定义
定义一系列算法,把它们一个个封装起来,并且使它们可互
相替换(变化)。该模式使得算法可独立于使用它的客户程
序(稳定)而变化(扩展,子类化) 。 --《设计模式》 GoF
- 什么是互相替换,就是支持变化。
- 上面程序中
SalesOrder
独立于税法的变化,SalesOrder
是稳定的。
4. 结构( Structure)
上图是《设计模式》GoF中定义的Strategy 策略模式的设计结构。结合上面的代码看图中最重要的是看其中稳定和变化部分,也就是下图中红框和蓝框框选的部分。
5. 要点总结
- Strategy及其子类为组件提供了一系列可重用的算法,从而可以使得类型在
运行时
方便地根据需要在各个算法之间进行切换。
结合上面的代码,这里运行时就指的是:
this->strategy = strategyFactory->NewStrategy();
运行时传递多态的对象,double val = strategy->Calculate(context); //多态调用
运行时支持多态的调用
- Strategy模式提供了用
条件判断语句
以外的另一种选择,消除条件判断语句,就是在解耦合。含有许多条件判断语句的代码通常都需要Strategy模式。
绝对不变的情况下是可以使用if…else的,但是在实际应用需要扩展的情况就要使用Strategy模式
- 如果Strategy对象没有实例变量,那么各个上下文可以共享同一个Strategy对象,从而节省对象开销。
Strategy
从某种层面来讲,可以使用后面要讲的Single
来设计的,从而节省对象开销。例如中国的税法里面没有实例变量的话,只创建全局一个对象就可以了
6.其他参考博文
Strategy 策略模式