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

Yesterday home runs don't win today games

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

什么是策略模式

针对策略模式的局限，又有哪些解决办法

枚举策略了解一下？

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

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

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

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

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

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

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

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

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

标准定义以及类图

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

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

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

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

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

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

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

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

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

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

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

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

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

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