常用设计模式--策略模式

从上图可以看到，我们将操作封装到类中，他们实现了同一个接口，然后在 Context 中调用。

这里我们举一个计算器的例子：

此例中，为加法和减法分别创建了一个类。

其实策略不一定要命名为 Strategy，Context 不一定要叫 Context，可以根据实际情况自己命名，在计算器的例子中，你如果非要命名为 Strategy 和 Context，反而让人产生疑惑。

实际代码也很简单，具体如下。

Operation 接口：

public interface Operation {
    public int doOperation(int num1, int num2);
}

两个实现类——加法和减法：

public class OperationAdd implements Operation{
    @Override
    public int doOperation(int num1, int num2) {
        return num1 + num2;
    }
}

public class OperationSub implements Operation {
    @Override
    public int doOperation(int num1, int num2) {
        return num1 - num2;
    }
}

计算器类：

public class Calculator {
    private Operation operation;

    public void setOperation(Operation operation){
        this.operation = operation;
    }

    public int doOperation(int num1, int num2){
        return this.operation.doOperation(num1,num2);
    }
}

使用：

Calculator calculator = new Calculator();
calculator.setOperation(new OperationAdd());
int result = calculator.doOperation(1,2);
System.out.println(result);

使用计算器类时，如果要进行加法运算，就 new 一个加法类传入，减法也是同理。

看到这里，相信大家一定会有疑惑，为什么要把加、减、乘、除四则运算分别封装到类中？直接在 Calculator 中写 add()、sub() 等方法不是更方便吗？

甚至如果要添加其他的运算方法，每次都要创建一个类，反而更麻烦。

的确用了策略模式之后代码比普通写法多了一些，但是这里假设一种场景：

假设把写好的计算器代码打包好作为一个库发布出去给其他人用，其他人发现你的计算器中只有加、减、乘、除四个方法，而他想增加平方、开方等功能，咋办？

如果是用普通写法写的计算器，想要增加功能唯一的办法就是修改你写好的 Calculator，增加平方和开方两个 method。

可是你提供的是一个 jar 包啊，jar 包，jar...jar...jar...jar...包……

就算你提供的是源码，你希望其他人可以随意的修改你写好的代码吗？一般我们发布出去的开源框架或库都是经过千锤百炼，经过测试的代码，其他人随意修改我们的源码很容易产生不可预知的错误。

如果你用的是策略模式，那么其他人想要增加平方或开平方功能，只需要自己定义一个类实现你的 Operation 接口，然后调用 calculator.setOperation(new 平方类()); 即可。

看到这里相信你已经对策略模式有了一定的好感，甚至惊叹一声：哇，还有这种操作？

顺便提一嘴，这里很好的体现了一个设计模式的基本原则：开闭原则。

开闭原则说的是 对修改关闭、对扩展开放。

对修改关闭就是不希望别人修改我们的代码，此路不通，对扩展开放就是希望别人以扩展的方式增加功能，策略模式把开闭原则体现得淋漓尽致。

优点

讲完上面的例子，优点已经十分明显了，那就是遵循了开闭原则，扩展性良好。

转载自:https://gitbook.cn/gitchat/column/5b1e3647294fb04d7c22b783/topic/5b1fa42a52823b7111033332