设计模式总结之Strategy Pattern（策略模式）

目录

• 设计模式分类
  

创建型设计模式：

• Singleton Pattern（单例模式）   
  

• Prototype Pattern（原型模式）

• Factory Method Pattern（工厂方法模式）   
  

• Abstract Factory Pattern（抽象工厂模式）

• Builder Pattern（建造者模式）

结构型设计模式：

• Adapter Pattern（适配器模式）   
  

• Bridge Pattern（桥接模式）

• Composite Pattern（组合模式）

• Decorator Pattern（装饰者模式）

• Façade Pattern（外观模式）

• Flyweight Pattern（享元模式）

• Proxy Pattern（代理模式）   
  

行为型设计模式：

• Chain of Responsibility Pattern（职责链模式）

• Command Pattern（命令模式）

• Interpreter Pattern（解释器模式）   
  

• Iterator Pattern（迭代器模式）

• Mediator Pattern（中介者模式）

• Memento Pattern（备忘录模式）

• Observer Pattern（观察者模式）

• State Pattern（状态模式）

• Strategy Pattern（策略模式）

• Template Method Pattern（模板方法模式）

• Visitor Pattern（访问者模式）

Strategy Pattern（策略模式）

意图

定义一系列的算法,把它们一个个封装起来, 并且使它们可相互替换。本模式使得算法可独立于使用它的客户而变化。

适用性

1. 许多相关的类仅仅是行为有异。“策略”提供了一种用多个行为中的一个行为来配置一个类的方法。
2. 需要使用一个算法的不同变体。例如，你可能会定义一些反映不同的空间/时间权衡的算法。当这些变体实现为一个算法的类层次时，可以使用策略模式。
3. 算法使用客户不应该知道的数据。可使用策略模式以避免暴露复杂的、与算法相关的数据结构。
4. 一个类定义了多种行为, 并且这些行为在这个类的操作中以多个条件语句的形式出现。将相关的条件分支移入它们各自的Strategy类中以代替这些条件语句。

结构

参与者：
> Strategy(策略) 
— 定义所有支持的算法的公共接口。Context使用这个接口来调用某 ConcreteStrategy定 义的算法。 
> ConcreteStrategy(具体策略) 
— 以Strategy接口实现某具体算法。 
> Context(上下文)?
— 用一个ConcreteStrategy对象来配置。
— 维护一个对Strategy对象的引用。
— 可定义一个接口来让Stategy访问它的数据。 

例子

优缺点

> 优点：
* 算法可以自由切换
这是策略模式本身定义的，只要实现抽象策略，它就成为策略家族的一个成员，通过封装角色对其进行封装，保证对外提供“可自由切换”的策略。  
* 避免使用多重条件判断
如果没有策略模式，我们想想看会是什么样子？一个策略家族有5个策略算法，一会要使用A策略，一会要使用B策略，怎么设计呢？使用多重的条件语句？多重条件语句不易维护，而且出错的概率大大增强。使用策略模式后，可以由其他模块决定采用何种策略，策略家族对外提供的访问接口就是封装类，简化了操作，同时避免了条件语句判断。   
* 扩展性良好
这甚至都不用说是它的优点，因为它太明显了。在现有的系统中增加一个策略太容易了，只要实现接口就可以了，其他都不用修改，类似于一个可反复拆卸的插件，这大大地符合了OCP原则。

> 缺点：
* 策略类数量增多
每一个策略都是一个类，复用的可能性很小，类数量增多。   
* 所有的策略类都需要对外暴露
上层模块必须知道有哪些策略，然后才能决定使用哪一个策略，这与迪米特法则是相违背的，我只是想使用了一个策略，我凭什么就要了解这个策略呢？那要你的封装类还有什么意义？这是原装策略模式的一个缺点，幸运的是，我们可以使用其他模式来修正这个缺陷，如工厂方法模式、代理模式或享元模式。