设计模式理解：策略模式

策略模式，又称政策模式，一种对象行为型模式。定义一系列算法，把他们用一个个类封装起来，并使它们可以相互替换。该模式中使得算法可以独立于使用与使用它的客户程序中。

实现方式是：类的继承和多态的形式创建对象

例如，在算法实现中要根据情况不同而走不同的分支，各个分支都是做相同的算法但是又各个独立。

例如，关于计算税收的一个方法，要支持中国、日本、美国的税务计算，有如下两种实现方式

enum countryType{
 CN,
 US,
 JP
}
class ctax{
public:
countryType type;
int caltax (Object param){
    switch(type){
    case CN:
        //中国的税务计算
        break;
    case US:
        //美国的税务计算
        break;
    case JP:
        //日本的税务计算
        break;
    default：
        .....
    }
  
}

第二种：

class taxStrategy{
    virtual int caltax (Object param)=0;
}
class cnTaxStrategy:pubilc taxStrategy{
    virtual int caltax (Object param){/**中国的税务计算**/};
}
class usTaxStrategy:pubilc taxStrategy{
countryType type;
    virtual int caltax (Object param){/**美国的税务计算**/};
}
class jpTaxStrategy:pubilc taxStrategy{
countryType type;
    virtual int caltax (Object param){/**日本的税务计算**/};
}


class ctax{
public:
countryType type;
int caltax (Object param){
   taxStrategy* strategy = newStrategy(); //创建实体
   strategy->caltax(param) ;
}

在这两种例子中客户的应用程序是ctax。假如有一个需求“新增英国税收的算法”，那么第一种代码，就要新增枚举，延长switch...case..的实现方式。而第二种方式需要新创建一个派生类且扩展对象实例化方法newStrategy()。

虽然在功能上需求上，两者方法都可以实现。但是从可维护性来讲，无疑第一种方式是比较差的。假如算法复杂度过高，或者将来又有扩展不同国家税收需求。那么第一种方法实现起来代码量就会很大，误操作引发的生产事故的概率就会变大。从可复用性来讲，假如其他项目需要复用税收的代码，那么第一种方式只能是Ctrl CV，而第二种方式实现了算法和应用程序的分离，对于算法变更不会影响到客户程序ctax。又例如，把这套程序提供给中国的用户，该中国用户只需要中国的税收算法，不需要支持其他国家税收。那么第一种方式就会不可避免的将大量的无用算法代码编译进工程中，降低性能。

所以,每当当使用if...elseif... 或者 switch...case 就要考虑到是否策略模式更适合。当然，对于可穷举的条件判断 if...elseif..是合适的，例如性别，月份。但是对于不可穷举的条件判断或者判断条件会根据业务需求变化的时候就需要进行特别的考虑。策略模式最主要的目的是为了新增业务需求时减少代码开发、维护、测试工作量、减小新需求涉及到的影响范围。

设计模式理解：策略模式

猜你喜欢