iamamg97

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

每章一句

Yesterday home runs don't win today games

前言

哈喽,大家好,今天要分享的知识点是关于策略模式的使用,观看本文章可能需要耗费【8】分钟,通过本文,你可以认识到以下几个知识点

  • 什么是策略模式
  • 针对策略模式的局限,又有哪些解决办法
  • 枚举策略了解一下?

情景带入

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

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

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

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

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

开始分析

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

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

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

image-20211202103437081

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

image-20211202103937268

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

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

策略模式

标准定义以及类图

定义一组算法,并封装每个算法,让它们彼此可以交换使用。策略模式让这些算法在客户端中使用起来更加独立

image-20211202142525934

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

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

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

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

尝试编码

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

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

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

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

image-20211202145103765

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

  • 首先是顶层接口代码

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

  • Context代码

  • 客户端调用情况

    输出结果

    image-20211202150316134

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

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

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

策略模式的优点

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

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

策略模式的局限

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

设计模式的定义告诉我们,问题包含了一个目标和一组约束;光明的方向就是你的目标,黑暗的方向就是这些约束

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

相关文章: