大话设计模式笔记 - 策略模式

大话设计模式笔记 - 策略模式

本文的案例是一个商场促销的案例。

我们去商场购物时，结算系统是必不可少的一个环节。

输入：商品的单价，个数
输出：总共要付的金额

我们按照思路巴拉巴拉写完了，在看了上篇文章简单工厂模式之后，我们会避免业务逻辑和界面逻辑堆叠在一起，将他们分开编写。这是最基本的也是我们最先想到的。

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类)不仅持有该 *实现类* 的对象， 
   而且操该对象，直接获得我们需要的结果。
   但具体 *实现类* 的选择仍放在客户端。
   
   缺点就是并不能完全实现客户端的解耦。