策略模式(strategy pattern)
策略模式(strategy pattern) 的原始定义是：定义一系列算法，将每一个算法(业务)封装起来，并使它们可以相互替换。策略模式让算法(业务) 可以 独立于使用它的客户端而变化。
我们在现实生活中常常遇到实现某种目标存在多种策略可供选择的情况，例如，出行旅游可以乘坐飞机、乘坐火车、骑自行车或自己开私家车等。
in short 将不同的逻辑封装为一个个'策略'对象; 统一使用'策略执行器' 调用执行, 避免if...elseif膨胀; (对扩展开放, 对修改关闭 符合开闭原则);
UML类图
代码实例
例, 一个计算器, 算法功能逻辑是不断增加，如乘法、除法、次方、开方等等; 我们可以抽离出来, 封装为个策略
1.算法的抽象 (算法操作标准)
public interface Strategy {//算法操作标准public int calculate(int a, int b);//操作数，被操作数
}
2.'加法' 和 '减法' 算法实现
//加法
public class Addition implements Strategy{//实现算法接口 <!>具体策略实现策略@Overridepublic int calculate(int a, int b) {//加数与被加数return a + b;//这里我们做加法运算}}
//减法
public class Subtraction implements Strategy{//实现算法接口@Overridepublic int calculate(int a, int b) {//减数与被减数return a - b;//这里我们做减法运算}
}
3.计算器类(策略执行器)
public class Calculator {//计算器类private Strategy strategy;//拥有某种算法策略public void setStrategy(Strategy strategy) {//接入算法策略this.strategy = strategy;}public int getResult(int a, int b){return this.strategy.calculate(a, b);//返回具体策略的结果}
}
4. 测试 (客户端)
public class Client {public static void main(String[] args) {Calculator calculator = new Calculator();//实例化计算器calculator.setStrategy(new Addition());//接入加法实现int result = calculator.getResult(1, 1);//计算！System.out.println(result);//得到的是加法结果2calculator.setStrategy(new Subtraction());//再次接入减法实现result = calculator.getResult(1, 1);//计算！System.out.println(result);//得到的是减法结果0}
}
策略模式(strategy pattern) 总结
将创建, 定义, 使用 这三部分解耦!
关键角色
- 抽象策略 (定义策略标准)
- 具体策略实现
- 策略执行器 (接入和执行策略)
策略模式优缺点
1) 策略模式优点：
-
策略类之间可以自由切换
由于策略类都实现同一个接口，所以使它们之间可以自由切换。 -
易于扩展
增加一个新的策略只需要添加一个具体的策略类即可，基本不需要改变原有的代码，符合“开闭原则“ -
避免使用多重条件选择语句（if else），充分体现面向对象设计思想。
2) 策略模式缺点：
- 客户端必须知道所有的策略类，并自行决定使用哪一个策略类。
- 策略模式将造成产生很多策略类，可以通过使用享元模式在一定程度上减少对象的数量。
策略模式适用场景
-
一个系统需要动态地在几种算法中选择一种时，可将每个算法封装到策略类中。
策略模式最大的作用在于分离使用算法的逻辑和算法自身实现的逻辑，这样就意味着当我们想要优化算法自身的实现逻辑时就变得非常便捷，一方面可以采用最新的算法实现逻辑，另一方面可以直接弃用旧算法而采用新算法。使用策略模式能够很方便地进行替换。
-
一个类定义了多种行为，并且这些行为在这个类的操作中以多个条件语句的形式出现，可将每个条件分支移入它们各自的策略类中以代替这些条件语句。
在实际开发中，有许多算法可以实现某一功能，如查找、排序等，通过 if-else 等条件判断语句来进行选择非常方便。但是这就会带来一个问题：当在这个算法类中封装了大量查找算法时，该类的代码就会变得非常复杂，维护也会突然就变得非常困难。虽然策略模式看上去比较笨重，但实际上在每一次新增策略时都通过新增类来进行隔离，短期虽然不如直接写 if-else 来得效率高，但长期来看，维护单一的简单类耗费的时间其实远远低于维护一个超大的复杂类。
-
系统要求使用算法的客户不应该知道其操作的数据时，可使用策略模式来隐藏与算法相关的数据结构。
如果我们不希望客户知道复杂的、与算法相关的数据结构,在具体策略类中封装算法与相关数据结构,可以提高算法的保密性与安全性.
设计原则和思想其实比设计模式更加的普适和重要, 掌握了代码的设计原则和思想,我们自然而然的就可以使用到设计模式,还有可能自己创建出一种新的设计模式.