原理与实现
定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略 模式可以使算法的变化独立于使用它们的客户端(这里的客户端代指使用算法的代码)。
我们知道，工厂模式是解耦对象的创建和使用，观察者模式是解耦观察者和被观察者。策略 模式跟两者类似，也能起到解耦的作用，不过，它解耦的是策略的定义、创建、使用这三部分。接下来，我就详细讲讲一个完整的策略模式应该包含的这三个部分。
策略的定义
策略的创建
策略模式会包含一组策略，在使用它们的时候，一般会通过类型(type)来判断创建 哪个策略来使用。为了封装创建逻辑，我们需要对客户端代码屏蔽创建细节。我们可以把根 据 type 创建策略的逻辑抽离出来，放到工厂类中。
一般来讲，如果策略类是无状态的，不包含成员变量，只是纯粹的算法实现，这样的策略对 象是可以被共享使用的，不需要在每次调用 getStrategy() 的时候，都创建一个新的策略对 象。针对这种情况，我们可以使用上面这种工厂类的实现方式，事先创建好每个策略对象， 缓存到工厂类中，用的时候直接返回。
相反，如果策略类是有状态的，根据业务场景的需要，我们希望每次从工厂方法中，获得的 都是新创建的策略对象，而不是缓存好可共享的策略对象，那我们就需要按照如下方式来实现策略工厂类。
策略的使用
策略模式包含一组可选策略，客户端代码一般如何确定使用哪个策略呢?最常见的是运行时动态确定使用哪种策略，这也是策略模式最典型的应用场景。
这里的“运行时动态”指的是，我们事先并不知道会使用哪个策略，而是在程序运行期间， 根据配置、用户输入、计算结果等这些不确定因素，动态决定使用哪种策略。
避免分支判断
实际上，能够移除分支判断逻辑的模式不仅仅有策略模式，后面我们要讲的状态模式也可以。对于使用哪种模式，具体还要看应用场景来定。 策略模式适用于根据不同类型待动态，决定使用哪种策略这样一种应用场景。
未优化前
我们没有使用策略模式，而是将策略的定义、创建、使用直 接耦合在一起。
优化后
重构之后的代码就没有了 if-else 分支判断语句了。实际上，这得益于策略工厂类。在工厂类中，我们用 Map 来缓存策略，根据 type 直接从 Map 中获取对应的策略，从而避免 if- else 分支判断逻辑。等后面讲到使用状态模式来避免分支判断逻辑的时候，你会发现，它们使用的是同样的套路。本质上都是借助“查表法”，根据 type 查表(代码中的 strategies 就是表)替代根据 type 分支判断。
但是，如果业务场景需要每次都创建不同的策略对象，我们就要用另外一种工厂类的实现方 式了。具体的代码如下所示:
这种实现方式相当于把原来的 if-else 分支逻辑，从 OrderService 类中转移到了工厂类 中，实际上并没有真正将它移除。
总结
策略模式定义一族算法类，将每个算法分别封装起来，让它们可以互相替换。策略模式可以 使算法的变化独立于使用它们的客户端(这里的客户端代指使用算法的代码)。
策略模式用来解耦策略的定义、创建、使用。实际上，一个完整的策略模式就是由这三个部分组成的。
策略类的定义比较简单，包含一个策略接口和一组实现这个接口的策略类。 策略的创建由工厂类来完成，封装策略创建的细节。
策略模式包含一组策略可选，客户端代码如何选择使用哪个策略，有两种确定方法:编译时静态确定和运行时动态确定。其中，“运行时动态确定”才是策略模式最典型的应用场景。
除此之外，我们还可以通过策略模式来移除 if-else 分支判断。实际上，这得益于策略工厂类，更本质上点讲，是借助“查表法”，根据 type 查表替代根据 type 分支判断。