策略模式 设计模式

谁来决定使用哪个策略？

是策略客户方角色

大家要注意一下，这个模式的一个非常重要的一点，就是谁来决定使用哪个策略，一般大部分人会想当然的认为，应该是策略代理方来做这个决定，但是从原著里面看，而且作者反复强调，是策略客户方角色做这个决定，这一点大家要非常注意。

PromotionService，促销服务实现类，作为策略代理方，从上面的代码中看，它确实挺简单的，就是做了一下请求转发，直接调用了促销策略对象的方法。那是因为我们的案例比较简单。这个对象里面其实还可以有很多事情可以干，比较常见的就是，执行具体的策略算法，除了上游传过来的业务数据，可能还需要该算法需要的特定数据，这些都需要策略代理方自己去封装。如果没有策略代理类，那么这些事情，就只能由策略客户方来解决了。这也是这个模式之所以产生的根本原因。

如何降低代码重复率

可以有以下几个思路：

1，充分利用特定状态服务方继承的抽象类：这个方法，我们在上面已经使用过了，我们在抽象类中，实现了状态控方法的默认实现（这个其实就是钩子方法），这种方法，基于继承实现代码复用，缺点是会造成抽象类体积急剧膨胀。 – 继承（多态）方式

2，给状态控方法，建立专用的辅助类：我们可以针对某些复杂的，代码重复率比较高的受控方法，建立专门的辅助类，以组合的方式实现代码复用。— 组合方式

3，状态模式的二次方：假设把所有状态分为几个状态组，某个状态控方法在每个组的代码是重复的，这个时候，我们就可以给这个状态控方法，再使用一次状态模式，也就是状态模式嵌套状态模式，有点看热闹的不怕事大，一个就已经够复杂的了，再嵌入一个，是不是更复杂，实际恰恰相反。

第三个思路有点意思