C++设计模式_04_Strategy 策略模式

接上篇，本篇将会介绍C++设计模式中的Strategy 策略模式，和上篇模板方法Template Method一样，仍属于“组件协作”模式，它与Template Method有着异曲同工之妙。

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来设计的，从而节省对象开销。例如中国的税法里面没有实例变量的话，只创建全局一个对象就可以了