设计模式之策略模式

设计模式之策略模式

策略模式的简单介绍

策略模式(Strategy)，二十三中设计模式之一，是一种比较常用的设计模式，策略模式，顾名思义，一种跟策略有关的设计模式，主要的思想是，当面对同一件事情有多种不同的解决方案的时候，根据不同的选择方案采用不同的策略，每一种策略都是一个独立的个体，这样子，当增加新的方案的时候，可以不用更改原有的代码，而直接编写新的策略，然后使用该策略即可，符合设计原则中的“开闭原则”，同时也使得代码的结构更加清晰，更加容易理解

策略模式的具体实现

假设现在我们在编写一个业务，比如说宽带办理业务，这个业务有多种不同的方案，比如说下面几种形式
- 经济型：20M带宽，每年666元
- 商务型：50M带宽，每年888元
- 豪华型：100M带宽，每年1000元
- 土豪型：1G带宽，每年100000元

在没有采用策略模式的时候，我们可能为按照下面的方式来实现

public void setupBandWidth(String type){
    if ("经济型".equalsIgnoreCase(type)){
        System.out.println("办理经济型套餐");
    }else if ("商务型".equals(type)){
        System.out.println("办理商务型套餐");
    }else if ("豪华型".equals(type)){
        System.out.println("办理豪华型套餐");
    }else if ("土豪型".equals(type)){
        System.out.println("办理土豪型套餐");
    }
}

单纯从实现上来说，这样子的实现是没有问题，但是当遇到业务需要不断扩展的时候，比如说增加两个新的套餐，这种直接硬编码的方式的缺点就出现了，每一次套餐的变化，我们都需要修改代码，这就违背了“开闭原则”了。这种实现方式不仅仅使得代码的结构变得庞大，还会在无形之中给每次修改都带来了危机。

接下来我们来看下采用策略模式之后的代码

/**
 * 策略接口
 */
interface BandWidthStrategy{
    void BandWidthService();
}

/**
 * 不同类型的策略
 */
class EconomicType implements BandWidthStrategy{

    @Override
    public void BandWidthService() {
        System.out.println("办理经济型套餐");
    }
}

class BusinessType implements BandWidthStrategy{

    @Override
    public void BandWidthService() {
        System.out.println("办理经济型套餐");
    }
}

class Luxurious implements BandWidthStrategy{

    @Override
    public void BandWidthService() {
        System.out.println("办理豪华型套餐");
    }
}

class TyrantType implements BandWidthStrategy{

    @Override
    public void BandWidthService() {
        System.out.println("办理土豪型套餐");
    }
}

/**
 * 服务上下文，主要是用于进行策略的切换
 */
class Context{
    private BandWidthStrategy bandWidthStrategy;

    public void setBandWidthStrategy(BandWidthStrategy bandWidthStrategy) {
        this.bandWidthStrategy = bandWidthStrategy;
    }

    public void service(){
        bandWidthStrategy.BandWidthService();
    }
}

可以看到，通过上面这种方式，代码的结构非常清新，用户选择对应的套餐，然后由客服为用户办理该套餐，而且，当要增加新的套餐的时候，我们不需要修改上面的任何代码，只需要编写新的套餐，然后实现我们的策略接口即可。

总结

策略模式主要是用于解决一种问题有多种不同的解决方案的时候，可以有效地避免了丑陋的代码结构，同时避免了在新增加新内容的时候需要修改原代码，当然，随着而来的是，类，或者说解决方案组的类的数量变多了。