大话设计模式笔记 - 策略模式
本文的案例是一个商场促销的案例。
我们去商场购物时，结算系统是必不可少的一个环节。
输入：商品的单价，个数
输出：总共要付的金额
我们按照思路巴拉巴拉写完了，在看了上篇文章简单工厂模式之后，我们会避免业务逻辑和界面逻辑堆叠在一起，将他们分开编写。这是最基本的也是我们最先想到的。
1.1 增加折扣
如果现在赶上商品打折，代码要怎么设计呢？如果现在是7折，明天是5折呢？如果是满200 - 100 呢？
这个时候我们就想到了工厂模式。
设计一个Factory类和一个顾客应付金额的基类 CashSuper。
CashSuper类提供支付金额的计算方法。
全价类、折扣类和返现类都继承CashSuper类，实现上面的方法。
之后，我们可以在客户端调用工厂模式，根据不同的活动输入，得到不同的CashSuper的实现类对象。从而获得用户的支付金额。
CashSuper imp = CashFactory.createCashImp("活动类型")
float result = imp.GetResult("单价" * "数量")
1.2 增加积分政策
如果增加了新的优惠政策，购物100积分10，一定积分可以换取奖品。我们该怎么处理呢？
1> 增加积分兑换实现类，继承CashSuper
2> 修改factory中，switch case 选择实现类的逻辑。
3> 在客户代码中，添加新的优惠方式的处理逻辑。
这种耦合程度显然是我们不想看到的。
那有没有一种设计模式，面对算法的时常变动，不会影响到使用算法的客户呢？
2 策略模式
策略模式定义了算法家族，分别封装算法，让其可以互相替换，且算法的变化不会影响到使用算法的客户。
1> 定义CashContext类，
通过构造方法传入CashSupter的实现类Impl策略，
并让CashContext持有该Impl对象。
同时定义方法，在方法中调用Impl中的目标方法。
2> 客户端通过switch case，选择Impl策略，
并将其传入CashContext中。
3> 通过CashContext类操作Impl,
将最终的结果返回给客户。
这样，如果有新的算法策略变动，我们需要做的是：
1> 添加新的策略实现类。
2> 在客户端switch case 中添加对应的选项。
在调用策略的客户类中，不会再有其他的变动，只需要接收算法处理后的结果即可。
这样，我们就实现了算法的互相替换。
但这也只能说是减少了算法对客户的影响，因为 switch case 还在，我们还需要修改这部分代码。这不能说是完全解耦。那我们该如何进一步完善呢？
3 简单工厂模式和策略模式的结合
我们只需要将 switch case 的选择逻辑移植到CashContext中，
就可以完全实现客户和算法的解耦。
就是这么简单。
简单工厂模式和策略模式结合之后，与之前简单工厂模式相比，最重要的特点：
算法的变化能否影响到使用算法的客户代码。
这也是策略模式最重要的特点，但如果需要彻底解耦，还是需要工厂和策略相结合才可以。
4 简单工厂模式和策略模式的区别
1> 简单工厂模式
将CashSuper的实现类的选择放在了工厂当中，
并不对 *实现类* 进行任何操作，
而是放在了客户端。
这么做的缺点就是，如果出现一种新的算法，
若该算法并不适用于已有的逻辑，有可能会使客户代码做出大量的修改。
--
2> 策略模式
Context类(相当于工厂模式中Factory类)不仅持有该 *实现类* 的对象，
而且操该对象，直接获得我们需要的结果。
但具体 *实现类* 的选择仍放在客户端。
缺点就是并不能完全实现客户端的解耦。
