【设计模式】汉堡中的设计模式——策略模式

每章一句

前言

情景带入

话说昨天，麦当劳搞活动，板烧只要5块大洋！！！下班了之后我就骑着心爱的小摩托飞奔过去，在等待了一段（long）时（long）间（time）...... 终于如愿以偿的握着这简单的快乐

看着手里的板烧，心里突然就有了一些想法，现在搞活动，部分商品低价就可以拿到，但是搞活动不能一直搞吧，那不然肯定亏大本了，活动形式也总不能一成不变吧，需要保持新颖，多元化吸引顾客消费

那么变化点就出来了，这个形式是可以不断变化的，例如会有这么几种

打折活动的时候，只需要5块大洋就能拿下一个汉堡
买一送一活动的时候，原价可以拿到两个
优惠券活动，有的时候是有一些优惠券的，达到门槛减多少
没有活动时，需要原价购买

我们常说要透过现象看本质，尽管形式很多，但是万变不离其中，最终是要付钱产生价值的，那就来分析一下这个流程吧！

开始分析

我们再来模拟一下，顾客在各种形式下是怎么点餐的

没有活动时，我把汉堡添加到购物车，创建订单，支付，等待出餐
搞打折活动时，汉堡只需要5块大洋，通过指定链接，把汉堡加到购物车，创建订单，支付，等待出餐
搞买一送一活动时，把汉堡添加到购物车，创建订单，支付，等待出餐
搞满减活动时，把汉堡和中薯、那么大鸡排添加到购物车，凑足满减金额，创建订单，使用优惠券，支付出餐

通过画图的形式展示一下上述的逻辑

上面是完整的步骤，简化一下，我们只关注产生价值的部分，也即客户支付了多少钱，取到了哪些食物

进一步说就是，商户可以随意切换形式，比如昨天有5元的板烧，今天点进去看发现没有了，但是多出来了其他的优惠，例如【麦乐鸡20粒】优惠券，后天进去发现优惠券都没了，只能原价购买等情况；但是无论形式是这样的，最终产出时的步骤都是一致的，例如这里就是支付和取餐

绕了这么久，其实就是要引出今天的主角————策略模式

策略模式

标准定义以及类图

如果以上述例子来看，所有形式都是一种特定的算法

原价购买是一种算法
打折也是一种算法
优惠券满减也是算法
买一送一也是算法
....

算法具体的如何实现的，客户端不管，客户端只知道，我可以任意切换形式，并且达成想要的效果

就好比顾客知道有这个活动，但不用知道这个活动的其他细节，我只需要按照步骤操作即可有优惠

尝试编码

既然上述几种情况最终都需要支付和取餐，那么我们直接就定义一个顶层接口管理这些算法（相当于是AbstractStrategy），接口中有两个方法

一个是返回实际需要付多少钱
一个是返回实际取到的食物列表

具体如何实现，就是每个算法内部的事情了，别人管不了，相当于是每一个ConcentrateStrategy

从类图上看到，标准的策略模式还要有一个组件Context，他就类似是策略模式的客户端，要调用哪一个策略，跟Context沟通，不跟具体实现沟通，这样做的好处就是实现客户端（真正的调用方）与具体实现间的解耦，如下图所示

所以，根据设计，我们把代码给敲一下

首先是顶层接口代码

然后是各个具体算法的实现

Context代码

客户端调用情况

输出结果

如果我要新添加一种形式呢？

麦当劳“壕无人性”地说，今天薯条免费赠送，那么针对这种情况，很明显现有的算法家族是不支持的，那么我们只需要再添加一种算法，叫做【FreePrice】，然后交给Client调用即可

我们完全不需要动其他已经写好的算法，这很符合OCP原则，并且算法的具体实现也被完美的隐藏在各个实现类中，实在是很nice

策略模式的优点

其实刚刚也讲了，这里再总结一下

算法的具体实现封装在各个实现类中，客户端不需要知道
客户端可以根据场合随意切换到底要使用哪一种策略
将客户端与具体实现通过Context解耦，即符合OCP原则，又可以让具体算法独立发展而不会影响其他类修改

策略模式的局限

那么，可能有小伙伴就像提问了，策略模式这么牛逼，他就没有一点局限性吗？这里引用我在看《Head First 设计模式》中看到的一段话，他的意思是

光明与黑暗总是相伴而生，所以策略模式的约束是什么？不妨从我们实际调用的方向入手，思考一下🤔

商户在实际设置新行为的时候，肯定是会有一个UI界面，会有下拉选择本次要推出的形式，针对不同的形式，所需要的参数也不尽相同，例如形式是优惠卷满减的时候，需要有满减阈值，满减多少，优惠券时效等等参数

那么发送到后端创建的时候，url请求也许是这样子的（简单给个例子）：newActivity?type=1

其中type就是标识，我们具体选择的策略，比如

type=1代表是原价
type=2代表是打折
type=3代表是满减

然后回看一下刚刚写的代码，在Client端调用，简直就是太过于理想化了，真正调用的时候，不可能这么写的

实际上，对应处理的Controller（客户端）在接收到方法的时候，最基础时要这么来判断

//伪代码,暂不校验字段有效性问题

if (1 == type)
    then xxxx
else if (2 == type)
    then xxxx
else if (3 == type)
    then xxxx
else if (4 == type)
    then xxxx
    
    ....

你说这个，跟我了解策略模式的局限性到底有什么关系啊？其实仔细品一下，就会发现，尽管我们把各个算法的实现细节都给隐藏了，当时我们依然需要知道有多少种策略，换言之就是，我们在选择策略的时候不免要进行判断，这就是策略模式一个局限

第二个就是，每次都需要新建一个类单独做一个算法策略，如果有很多很多的算法策略，就会导致类结构非常的膨胀，此时，就不易于维护和管理

解决局限性问题

针对客户端存在一大堆的if-else，我们使用简单工厂的形式配合把他们都封装起来

简单工厂+策略模式解决客户端大量if-else情况

原来的设计不变，把Context给替换成HandlerFactory，通过静态方法返回信息，这里为了更加贴合实际，定义了两个VO对象

简单工厂

最终客户端调用

使用postman进行测试，为了方便起见，参数就不改变了，就改变type，实际上是不同的type，参数也会不相同

type为1，原价方式

type为2，优惠券满减策略
type为3，折扣策略

type为4，买一送一策略

type为5，免费送策略

通过简单工厂+策略模式，我们把原本存在于客户端中的判断给挪到工厂里面，把所有的运行逻辑都隐藏起来了；每次有新的策略，只需要新建一个类，修改一下HandlerFactory中的selectStrategy方法即可

不过这也导致了HandlerFactory这个类违背了OCP原则，但是相对于一大段的if-else直接暴露再客户端，这种方法无疑是值得考虑的

枚举策略方式

或许在看完【简单工厂+策略模式】之后小伙伴会有所疑问，这不就是把客户端的判断逻辑给转移到工厂中而已，虽然对于客户端来说，会更加的清爽，可是似乎没有根本性的解决问题，工厂中把if-else换成了switch-case，新的策略该创建类还是要创建类，所以该膨胀还是得膨胀啊。。。

那没办法了，只能出绝招了，

使用枚举策略模式，相当于策略来说，枚举策略更像是他的改良升级版本，使用起来也更加的灵活，不需要创建大量的类来充当各个具体实现，也不需要满屏幕的if-else或者switch-case，看起来就相当的诱人

枚举大家都使用过，常用来定义一些常量信息，而枚举策略就是在枚举类里边加上抽象方法，让每个常量都实现这些方法

例如，我在枚举里边定义这两个方法

那么我的每一个枚举成员都必须实现这两个方法

给出完整的代码

客户端调用情况

可以发现，原本各个实现类都不需要了，只需要在枚举中定义成员，即可达成原来的效果，而且在匹配对应的策略时，直接使用循环的方式，看起来非常的清爽

如果要添加新的策略，直接在枚举里边添加成员，实现对应的方法即可，而且将所有的策略统一管理起来，方便维护

唯一的缺点，可能就是策略越来越多的时候，这个枚举类也会越来越长，但是通过成员来管理，注释写好，也不会显示很混乱

总结

所以，策略模式到底是什么？

就是提供很多很多的算法，让客户端可以动态的选择使用哪一个，其实在MVC中，View通过url把请求给到Controller处理，就是一种典型的策略选择，View可以随时更换url，绑定给另外一个Controller处理

事务都有两面性，所以针对策略模式的局限，我们需要做额外的工作，把不好的影响降到我们能接受的度

好啦，本期文章就到这里了，限于本人水平的问题，如果有说得不对的地方，欢迎指出！我们下期再见！

【设计模式】汉堡中的设计模式——策略模式