策略模式定义了算法簇，把它们一个个封装起来，并且使它们可相互替换。本模式使得算法可独立于它的使用者而变化
结构
参与者
- Strategy（策略）
定义所有支持算法的公共接口
- ConcreteStrategy（具体策略）
实现Strategy接口中的具体算法
- Context（上下文）
维护一个对Strategy对象的引用 为Strategy对象配置一个具体的ConcreteStrategy实现 通过ContextMethod方法将动作委托给ConcreteStrategy中定义的算法
适用场景
- 许多相关的类仅仅只是行为有异
- 需要适用一种算法的不同变体（如反应不同时间/空间权衡的算法）
- 算法中的数据结构和具体实现细节与用户无关
- 重构中发现一个类定义了多种行为，且这些行为在类的操作中以多个条件语句的形式出现
优点
- 以组合替代继承，将算法的实现与Context的实现分离开，且可以动态改变算法
- 封装变化，抽象出了业务中变化的部分（策略）
- 用户可以自己从不同的策略中权衡选择出最适合的一个
缺点
- 用户必须了解不同Strategy的区别
- Strategy和Context之间的通信依赖于Strategy定义的接口，简单的Strategy实现和复杂的Strategy实现需要用到的参数不同，但定义接口时需要考虑最复杂的情况，所以可能会导致使用简单的Strategy时会出现一些永远用不到的参数
Strategy与Context的数据通信
- 将Context中的数据放在参数中传递给ConcreteStrategy的AlgorithmInterface()方法，这使得Strategy与Context解耦，但Context可能发送一些Strategy不需要的数据
- 将Context自身作为一个参数传递给Strategy，该Strategy再显式地向该Context请求数据，或者Strategy持有一个Context的一个引用，这需要Context对它的数据定义一个更为精细的接口，会使得Strategy和Context耦合紧密
- Strategy持有一个Context泛型，这将会使得一个ConcreteStrategy和它的Context静态绑定在一起