设计模式之--策略模式

一、策略模式的介绍

软件开发中常遇到这种情况：实现某一个功能可以有多种算法或者策略，我们根据实际情况选择不同的算法或者策略来完成该功能。例如，排序算法，可以使用插入排序、归并排序、冒泡排序等。
针对这种情况，一种常规的方法是将多种算法写在一个类中。例如，需要提供多种排序算法，可以将这些算法写到一个类中，没一个方法对应一个具体的排序算法；当然，也可以将这些排序算法封装在一个统一的方法中，通过if…else…或者 case 等条件判断语句来选择具体的算法。这两种实现方法我们都可以称为硬编码。然而，当恒多个算法集中在一个类中时，这个类就会变得臃肿，这个类的维护成本会变高，在维护时也更容易引发错误。如果我们需要增加一种新的排序算法，需要修改封装算法类的源代码。这就明显违反了我们上面所说的OCP原则和单一职责原则。
如果将这些算法或者策略抽象出来，提供一个统一的接口，不同的算法或者策略有不同的实现类，这样在程序客户端就可以通过注入不同的实现对象来实现算法或者策略的动态替换，这种模式的可扩展性，可维护性也就更高，也就是我们要说的策略模式。

二、策略模式的定义
策略模式定义了一系列的算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化。

三、策略模式的使用场景

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

四、策略模式的UML类图

图中的角色介绍：

• Context —— 用来操作策略的上下文环境；
• Stragety —— 策略的抽象；
• ConcreteStragetyA、ConcreteStragetyB —— 具体的策略实现。

五、策略模式的简单实现
通常如果一个问题有多个解决方案时，最简单的方式就是利用 if-else 或者 switch-case 方式根据不同的情景选择不同的解决方案，但是这种简单的方案问题太多，例如耦合性太高、代码臃肿、难以维护等。但是，如果解决方案中包括大量的处理逻辑需要封装，或者处理方式变动较大的时候则就显示得混乱、复杂，当需要增加一种方案时就需要修改类中的代码。怎么对于修改不关闭？不是说好的要遵循开闭原则吗？

是的, if-else 这种方法确实不会遵循开闭原则，而应对这种情况策略模式就能很好地解决这类问题，它将各种方案分离开来，让程序客户端根据具体的需求来动态地选择不同的策略方案。

下面以在北京坐公共交通工具的费用计算来演示一个简单示例。在2014年12月28号之后，北京提高公交价格，不再试单一票价制，而是分段计价，也就是说乘坐的距离越远，价格越高。

显然，公交车和地铁的价格计算方式是不一样的，但是，我们的示例中是需要计算乘不同出行工具的成本，下面我们对上述示例用策略模式进行编码：

首先我们需要定义一个抽象的价格计算接口，就这命名为CalculateStrategy,具体代码如下：

/**
 * 计算接口
 */
public interface CalculateStrategy {
    /**
     * 按距离来计算价格
     * @param km 公里
     * @return 返回价格
     */
    int calculatePrice(int km);
}

对于每一种出行方式我们都有一个独立的计算策略类，这些策略类都实现了 CalculateStrategy 接口，例如下面是公家车、地铁、出租车的计算策略类：

/**
 * 公交车价格计算策略
 */
public class BusStrategy implements CalculateStrategy {
        /**
         * 北京公交车，十公里之内一元钱，超过十公里之后每加一元钱可以乘5公里
         * @param km 公里
         * @return 
         */
    @Override
    public int calculatePrice(int km) {
        // 超过10公里的总距离
        int extraTotal = km -10;
        // 超过的距离是5公里的倍数
        int extraFactor = extraTotal/5;
        //超过的距离对5公里取余
        int fraction = extraTotal%5;
        //价格计算
        int price = 1+extraFactor*1;
        return fraction > 0 ? ++price : price;
    }

}

//地铁价格计算策略
public class SubwayStrategy implements CalculateStrategy {
    /**
     * 6公里（含）内3元；6 ~ 12 公里（含）4元；12 ~ 22 公里（含）5元；22 ~ 32 公里（含）6 元。
     * 
     * @param km
     *            公里
     * @return
     */
    @Override
    public int calculatePrice(int km) {
        if (km <= 6) {
            return 3;
        } else if (km > 6 && km <= 12) {
            return 4;
        } else if (km > 12 && km <= 22) {
            return 5;
        } else if (km > 32 && km <= 32) {
            return 6;
        }
        // 其他距离我们简化为7元钱
        return 7;
    }
}

//出租车计算策略
public class TaxiStrategy implements CalculateStrategy {
    // 价格我们简单计算为公里数*5
    @Override
    public int calculatePrice(int km) {
        return km * 5;
    }
}

我们再创建一个扮演 Context 角色的类，这里将它命名为 TranficCalculator ，具体代码如下：

// 公共交通出行价格计算器
public class TranficCalculator {
    public static void main(String[] args) {
        TranficCalculator tranficCalculator = new TranficCalculator();
        // 设置计算策略
        tranficCalculator.setStrategy(new BusStrategy()); //公交车计算策略
//      tranficCalculator.setStrategy(new SubwayStrategy()); //地铁计算策略
//      tranficCalculator.setStrategy(new TaxiStrategy()); // 出租车计算策略
        // 计算价格
        System.out.println("车乘16公里的价格 ：" + tranficCalculator.calculatePrice(16));
    }

    // 设置计算策略
    CalculateStrategy mStrategy;

    private void setStrategy(CalculateStrategy mStrategy) {
        this.mStrategy = mStrategy;
    }

    // 计算价格
    public int calculatePrice(int km) {
        return mStrategy.calculatePrice(km);
    }
}

结构图如下：

通过建立抽象，将不同的策略构建成一个具体的策略实现，通过不同的策略实现算法替换。在简化逻辑、结构的同时，增强了系统的可读性、稳定性、可扩展性，这对于较为复杂的业务逻辑显得更为直观，扩展也更为方便。