实现动态替换-策略模式

模式介绍

通常，我们实现一个功能，可以有多种策略。
我们可以根据实际需求来选择最合适的策略。
针对这种情况，一种常规的方法就是将多种策略封装在一个类中，每个策略对应一个方法，在使用时通过if-else进行情况判断，不同情况调用不同方法来实现不同的策略。
这种实现方法我们可以称之为硬编码。

然而，当策略越来越多的时候，这个类就会变得臃肿，并且由于if-else等复杂逻辑的存在，在维护时会更容易产生错误，维护成本就会变高。
并且这种写法明显违反了面向对象中的开闭原则。
如果我们将这些策略的共同点抽象出来，提供一个统一的接口，不同的策略有着不同的实现，这样在客户端就可以通过注入不同的实现对象来实现动态替换。
这种模式的可扩展性、可维护性都是极高的。这，就是我们要说的策略模式。
总感觉，这模式，不就是多态嘛。。

模式定义

针对一个功能，将每一种解决方案封装起来，而且使它们可以相互替换，这就是策略模式。

使用场景

• 针对同一类型问题的多种处理方式，仅仅是具体行为存在差异；
• 需要安全地封装多种同一类型的操作时；
• 同一抽象类有多个子类，同时又需要使用if-else或swithc-case来选择具体子类时。

模式角色

• Strategy：策略抽象。
• ConcreteStrategy：具体策略，针对一个问题，有多少种策略，就应有多少个具体策略。

模式示例

2014年12月28日北京提高了公交、地铁的价格，不再是单一票价，而是分距离计价。
我们就根据上述需求，来做一个出行价格计算器。
话不多说，我们来实现这个功能：

简单做了计算器的UI，它应该提供具体出行方式的选择，很明显，我们提供了三种。
并且有一个出行距离的输入框。
在获取到出行方式和出行距离后，我们就可以来计算具体价格。
需求很明确，接下来我们要做的就是先实现各种出行方式下的价格计算：

public class PriceCaculateController {

    /**
     * 根据出行方式，选择距离的计算方法
     */
    public static float cacluatePrice(int km, int typeMode) {
        switch (typeMode) {
            case Constant.TYPE_BUS:
                return caculateBusPrice(km);
            case Constant.TYPE_SUBWAY:
                return caculateSubwayPrice(km);
            case Constant.TYPE_TAX:
                return caculateTaxPrice(km);
        }
        return 0;
    }

    /**
     * 计算出租车价格
     * 小于3Km，定价9元，大于3km，每1km + 1元
     *
     */
    private static float caculateTaxPrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 3) {
            return 9;
        }
        return 9 + (km - 3);
    }

    /**
     * 计算公交车价格
     * 小于5Km，定价2元，小于10km，定价3元，其余4元
     */
    private static float caculateBusPrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 5) {
            return 2;
        }
        if (km <= 10) {
            return 3;
        }
        return 4;
    }
    /**
     * 计算地铁价格
     * 小于5Km，定价3元，小于10km，定价4元，小于15Km，定价5元，其余6元
     */
    private static float caculateSubwayPrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 5) {
            return 3;
        }
        if (km <= 10) {
            return 4;
        }
        if (km <= 15) {
            return 5;
        }
        return 6;
    }
}

PriceCaculateController中包含了所有出行方式的计算细节。
细心的同学可以发现，我将PriceCaculateController中的所有计算方法私有化，向外暴露了一个cacluatePrice(int km, int typeMode)方法。
用户在使用时，仅需告诉我们出行距离与出行方式，我们就可以完全自动计算出价格，下面是使用的代码：

float price = PriceCaculateController.cacluatePrice(20,1);

这样我们就实现了页面与计算功能的完美解耦，页面完全不关心计算的细节。
接下来我们在页面上添加基础判断之后，调用PriceCaculateController.cacluatePrice即可。
我们可以来看看具体效果：

接下来我们就将价格计算功能进行抽象：

public interface StrategyCaculate {

    /**
     * 根据距离计算价格
     */
    float caculatePrice(int km);
}

策略抽象非常简单。
接下里我们来实现具体策略，有多少种出行方式，就应该有多少种具体策略：
公共汽车(Bus):

public class BusStrategyCaculate implements StrategyCaculate {
    @Override
    public float caculatePrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 5) {
            return 2;
        }
        if (km <= 10) {
            return 3;
        }
        return 4;
    }
}

出租车(Tax):

public class TaxStrategyCaculate implements StrategyCaculate {
    @Override
    public float caculatePrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 3) {
            return 9;
        }
        return 9 + (km - 3);
    }
}

地铁(Subway):

public class SubwayStrategyCaculate implements StrategyCaculate {
    @Override
    public float caculatePrice(int km) {
        if (km <= 0) {
            return 0;
        }
        if (km <= 5) {
            return 3;
        }
        if (km <= 10) {
            return 4;
        }
        if (km <= 15) {
            return 5;
        }
        return 6;
    }
}

三种出行方式对应三个具体策略。
当有新的出行方式时，我们只需创建新的类去实现策略抽象即可。
简单写一些测试代码：

StrategyCaculate caculate = null;
switch (typeMode) {
    case Constant.TYPE_BUS:
        caculate = new BusStrategyCaculate();
        break;
    case Constant.TYPE_SUBWAY:
        caculate = new SubwayStrategyCaculate();
        break;
    case Constant.TYPE_TAX:
        caculate = new TaxStrategyCaculate();
        break;
}
assert caculate != null;
return caculate.caculatePrice(km);

可以发现，这里我们又运用多态的特性，根据不同的出行方式，创建不同的子类，接着调用子类中的价格计算。
最后的效果和之前的效果是一致的。
相关代码已经提交至GitHub。

总结

有些人会有疑惑了，我们最开始的PriceCaculateController并不复杂，并且一个方法对应一种出行方式，清晰明了，为什么非要改成这个样子?
对于这个问题，我们现在的出行方式仅仅有三种、并且价格计算的逻辑非常简单。
如果现在继续添加出行方式：飞机、自驾、高铁、大巴等。
如果优化出租车的价格计算逻辑：出租车3Km以内9元，之后每1Km加1元，燃气费2元，堵车服务费每分钟0.1元，夜晚11点之后价格提升，每个城市的价格不同等等。
如果将上述逻辑全部写出，那么就出租车价格计算的逻辑，就要有上百行的代码。
如果你们公司是一家专业的出行价格计算公司，这些计算细节、出行方式都必定要涵盖到。
那么将来，PriceCaculateController的代码量，会有多大？
如果我们运用了策略模式，项目的目录结构就变成了：

• 结构清晰明了，使用简单；
• 降低耦合度，扩展方便；
• 封装彻底，数据更为安全。

所以，在你能预见到某个功能会有扩展的需求时，并且使用场景符合策略模式的使用场景，还是强烈建议你使用策略模式的。

感谢

《Android源码设计模式解析与实战》 何红辉、关爱民 著