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