【设计模式】汉堡中的设计模式——策略模式
- 【设计模式】汉堡中的设计模式——策略模式
- 每章一句
- 前言
- 情景带入
- 开始分析
- 策略模式
- 尝试编码
- 如果我要新添加一种形式呢?
- 策略模式的优点
- 策略模式的局限
- 解决局限性问题
- 简单工厂+策略模式解决客户端大量if-else情况
- 枚举策略方式
- 总结
每章一句
Yesterday home runs don't win today games
前言
哈喽,大家好,今天要分享的知识点是关于策略模式的使用,观看本文章可能需要耗费【8】分钟,通过本文,你可以认识到以下几个知识点
- 什么是策略模式
- 针对策略模式的局限,又有哪些解决办法
- 枚举策略了解一下?
情景带入
话说昨天,麦当劳搞活动,板烧只要5块大洋!!!下班了之后我就骑着心爱的小摩托飞奔过去,在等待了一段(long)时(long)间(time)...... 终于如愿以偿的握着这简单的快乐
看着手里的板烧,心里突然就有了一些想法,现在搞活动,部分商品低价就可以拿到,但是搞活动不能一直搞吧,那不然肯定亏大本了,活动形式也总不能一成不变吧,需要保持新颖,多元化吸引顾客消费
那么变化点就出来了,这个形式是可以不断变化的,例如会有这么几种
- 打折活动的时候,只需要5块大洋就能拿下一个汉堡
- 买一送一活动的时候,原价可以拿到两个
- 优惠券活动,有的时候是有一些优惠券的,达到门槛减多少
- 没有活动时,需要原价购买
我们常说要透过现象看本质,尽管形式很多,但是万变不离其中,最终是要付钱产生价值的,那就来分析一下这个流程吧!
开始分析
我们再来模拟一下,顾客在各种形式下是怎么点餐的
- 没有活动时,我把汉堡添加到购物车,创建订单,支付,等待出餐
- 搞打折活动时,汉堡只需要5块大洋,通过指定链接,把汉堡加到购物车,创建订单,支付,等待出餐
- 搞买一送一活动时,把汉堡添加到购物车,创建订单,支付,等待出餐
- 搞满减活动时,把汉堡和中薯、那么大鸡排添加到购物车,凑足满减金额,创建订单,使用优惠券,支付出餐
通过画图的形式展示一下上述的逻辑
上面是完整的步骤,简化一下,我们只关注产生价值的部分,也即客户支付了多少钱,取到了哪些食物
进一步说就是,商户可以随意切换形式,比如昨天有5元的板烧,今天点进去看发现没有了,但是多出来了其他的优惠,例如【麦乐鸡20粒】优惠券,后天进去发现优惠券都没了,只能原价购买等情况;但是无论形式是这样的,最终产出时的步骤都是一致的,例如这里就是支付和取餐
绕了这么久,其实就是要引出今天的主角————策略模式
策略模式
标准定义以及类图
定义一组算法,并封装每个算法,让它们彼此可以交换使用。策略模式让这些算法在客户端中使用起来更加独立
如果以上述例子来看,所有形式都是一种特定的算法
- 原价购买是一种算法
- 打折也是一种算法
- 优惠券满减也是算法
- 买一送一也是算法
- ....
算法具体的如何实现的,客户端不管,客户端只知道,我可以任意切换形式,并且达成想要的效果
就好比顾客知道有这个活动,但不用知道这个活动的其他细节,我只需要按照步骤操作即可有优惠
尝试编码
既然上述几种情况最终都需要支付和取餐,那么我们直接就定义一个顶层接口管理这些算法(相当于是AbstractStrategy),接口中有两个方法
- 一个是返回实际需要付多少钱
- 一个是返回实际取到的食物列表
具体如何实现,就是每个算法内部的事情了,别人管不了,相当于是每一个ConcentrateStrategy
从类图上看到,标准的策略模式还要有一个组件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,参数也会不相同
通过简单工厂+策略模式,我们把原本存在于客户端中的判断给挪到工厂里面,把所有的运行逻辑都隐藏起来了;每次有新的策略,只需要新建一个类,修改一下HandlerFactory中的selectStrategy方法即可
不过这也导致了HandlerFactory这个类违背了OCP原则,但是相对于一大段的if-else直接暴露再客户端,这种方法无疑是值得考虑的
枚举策略方式
或许在看完【简单工厂+策略模式】之后小伙伴会有所疑问,这不就是把客户端的判断逻辑给转移到工厂中而已,虽然对于客户端来说,会更加的清爽,可是似乎没有根本性的解决问题,工厂中把if-else换成了switch-case,新的策略该创建类还是要创建类,所以该膨胀还是得膨胀啊。。。
那没办法了,只能出绝招了,
使用枚举策略模式,相当于策略来说,枚举策略更像是他的改良升级版本,使用起来也更加的灵活,不需要创建大量的类来充当各个具体实现,也不需要满屏幕的if-else或者switch-case,看起来就相当的诱人
枚举大家都使用过,常用来定义一些常量信息,而枚举策略就是在枚举类里边加上抽象方法,让每个常量都实现这些方法
例如,我在枚举里边定义这两个方法
那么我的每一个枚举成员都必须实现这两个方法
给出完整的代码
客户端调用情况
可以发现,原本各个实现类都不需要了,只需要在枚举中定义成员,即可达成原来的效果,而且在匹配对应的策略时,直接使用循环的方式,看起来非常的清爽
如果要添加新的策略,直接在枚举里边添加成员,实现对应的方法即可,而且将所有的策略统一管理起来,方便维护
唯一的缺点,可能就是策略越来越多的时候,这个枚举类也会越来越长,但是通过成员来管理,注释写好,也不会显示很混乱
总结
所以,策略模式到底是什么?
就是提供很多很多的算法,让客户端可以动态的选择使用哪一个,其实在MVC中,View通过url把请求给到Controller处理,就是一种典型的策略选择,View可以随时更换url,绑定给另外一个Controller处理
事务都有两面性,所以针对策略模式的局限,我们需要做额外的工作,把不好的影响降到我们能接受的度
好啦,本期文章就到这里了,限于本人水平的问题,如果有说得不对的地方,欢迎指出!我们下期再见!