前言
传送地址：
设计模式已经到了第三篇，前两篇分别是代理模式与工厂模式，那么继续我们 23 篇设计模式的链路-策略模式。
策略模式
什么是策略模式？
策略模式的定义与特点
策略（Strategy）模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。此什么是策略模式处引用了 gof 设计模式的描述。
策略模式的主要优点如下：
- 多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句。
- 策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
- 策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
- 策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
- 策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。
其主要缺点如下：
- 客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。
- 策略模式造成很多的策略类。
策略模式的通俗理解
接着我们宠物店的🌰，我们除了招代理商之外，还可以引入互联网的大数据分析得出我们定向推荐的客户类型，提高服务质量
| 客户描述 | 宠物推荐 | 宠物照片 |
|---|---|---|
| 儿童客户：主要推荐一些比较乖巧，攻击性不高的小型犬 | 柴犬 | image
|
| 女性客户：主要推荐一些颜值较高的小型犬 | 萨摩耶，吉娃娃 | image
|
| 头铁客户：主要推荐一些特别折腾的，真的勇士型宠物 | 哈士奇 | image
|
上面的🌰都是单条件，然而在现实中的很多情况会复杂的多，比如客户会有跨越年龄、性别、生活习惯、家庭环境、个人性格等各种因素参杂在一快，所以用户行为画像是一个非常复杂而细致的事情，也导致我们在处理客户喜好的时候，会出现多重条件干扰因素，推荐算法会比较复杂。
项目实战
解决多重条件业务
多业务场景下的订单跳转一直是个很头疼的问题，因为每条业务的订单可能需要定制，跳转的详情也可能不太一样，当业务线过多的时候，很容易陷入多重条件地狱，不断去累加判断条件
const orderType = 1 // 1: 美妆，2：电器，3：家具
if (orderType === 1) {
console.log('美妆订单') // 简单是用打印方法来举例，实际可以当做每个订单条件跳转、展示的操作都不一样
} else if (orderType === 2) {
console.log('电器订单')
} else if (orderType === 3) {
console.log('家具订单')
}
如上这种，虽然是看起来条件很多但是属于单条件，我们可以使用策略模式来简单改造，如下所示：
const orderType = 1 // 1: 美妆，2：电器，3：家具
const orderFunction = {
1() { console.log('美妆订单') },
2() { console.log('电器订单') },
3() { console.log('家具订单') },
}
orderFunction[orderType]()
解决多重嵌套条件业务
但是我们的业务可能会更加复杂，订单页面我们采用了 h5 嵌入其他应用的模式，我们可能将此业务嵌入快应用、RN、原生 App、小程序、h5 等各种环境里面，展示的内容以及路由跳转可能都不尽相同，我们为了增加难度，更为直观的体现，所以每种对应的规则都默认是完全不同的方法。
const orderType = 1 // 1: 美妆，2：电器，3：家具
const orderWay = 1 // 1：h5，2：app，3：小程序
if (orderType === 1) {
if (orderWay === 1) {
console.log('美妆订单h5')
} else if (orderWay === 2) {
console.log('美妆订单app')
} else if (orderWay === 3) {
console.log('美妆订单小程序')
}
} else if (orderType === 2) {
if (orderWay === 1) {
console.log('电器订单h5')
} else if (orderWay === 2) {
console.log('电器订单app')
} else if (orderWay === 3) {
console.log('电器订单小程序')
}
} else if (orderType === 3) {
if (orderWay === 1) {
console.log('家具订单h5')
} else if (orderWay === 2) {
console.log('家具订单app')
} else if (orderWay === 3) {
console.log('家具订单小程序')
}
}
看到上述代码，可能人生已经绝望，因为实际中的订单类型远不止 3 种，环境类型也远不止 3 种，然而还可能有更多的附件条件并没有加上去。且越来越多的条件加入的同时，造成代码的可读性、可维护性、可迭代性急速下降，虽然上述代码格式化之后，看起来倒还是很工整的。
虽然上述是多重嵌套条件，但拆分开来还是可以理解为订单类型跟环境类型的组合，我们借助 es6 map 对象来进行改造
const orderType = 1 // 1: 美妆，2：电器，3：家具
const orderWay = 2 // 1：h5，2：app，3：小程序
const strategy = () => { // 订单类型+环境类型策略
const map = new Map([
[{
orderType: 1,
orderWay: 1
}, () => {
console.log('美妆订单h5')
}],
[{
orderType: 1,
orderWay: 2
}, () => {
console.log('美妆订单app')
}],
[{
orderType: 1,
orderWay: 3
}, () => {
console.log('美妆订单小程序')
}],
[{
orderType: 2,
orderWay: 1
}, () => {
console.log('电器订单h5')
}],
[{
orderType: 2,
orderWay: 2
}, () => {
console.log('电器订单app')
}],
[{
orderType: 2,
orderWay: 3
}, () => {
console.log('电器订单小程序')
}],
[{
orderType: 3,
orderWay: 1
}, () => {
console.log('家具订单h5')
}],
[{
orderType: 3,
orderWay: 2
}, () => {
console.log('家具订单app')
}],
[{
orderType: 3,
orderWay: 3
}, () => {
console.log('家具订单小程序')
}],
])
return map
}
const run = (orderType, orderWay) => {
let action = [...strategy()].filter(([key, value]) => (key.orderType === orderType && key.orderWay === orderWay))
action.forEach(([key, value]) => value.call(this))
}
run(orderType, orderWay)
如上述重构后的，我们借助 map 对象的特性（此处不对 map 对象做更深的拓展讲解）。如果再有新增的规则，我们可以放在 map 里面进行新增对应规则与方法，减少条件嵌套地狱出现，并且逻辑会更加清晰。但实际情况中还可以对类似的方法进行合并，逻辑会更加清晰。
解决多重嵌套条件地狱
上述的多种嵌套条件的解决方案是比较简单的，现实中很难有这么完美的条件判断出现。接下来见证一下什么叫地狱的风景
const orderType = 1 // 1: 美妆，2：电器，3：家具
const orderWay = 1 // 1：h5，2：app，3：小程序
const orderMoney = 100 // 金额范围划分，0-100，100-1000，1000以上，跳转的订单详情也不相同
if (orderType === 1) {
if (orderWay === 1) {
if (0 <= orderMoney && orderMoney < 100) {
console.log('美妆订单h5-0')
} else if (orderMoney < 1000) {
console.log('美妆订单h5-100')
} else {
console.log('美妆订单h5-1000')
}
} else if (orderWay === 2) {
if (0 <= orderMoney && orderMoney < 100) {
console.log('美妆订单app-0')
} else if (orderMoney < 1000) {
console.log('美妆订单app-100')
} else {
console.log('美妆订单app-1000')
}
} else if (orderWay === 3) {
if (0 <= orderMoney && orderMoney < 100) {
console.log('美妆订单小程序-0')
} else if (orderMoney < 1000) {
console.log('美妆订单小程序-100')
} else {
console.log('美妆订单小程序-1000')
}
}
} // 条件判断次数太多，所以此处只用了一层条件
我们来简单分析一下上述的条件，可以将相同的策略提取出来。首先环境跟订单类型的组合可以默认已知，所以将金额条件提取出来，当作一组策略返回
const orderType = 1 // 1: 美妆，2：电器，3：家具
const orderWay = 1 // 1：h5，2：app，3：小程序
const orderMoney = 10000 // 金额范围划分，0-100，100-1000，1000以上，跳转的订单详情也不相同
const orderMoneyStrategy = (orderMoney) => { // 提取金额策略
if (0 <= orderMoney && orderMoney < 100) {
return 1
} else if (orderMoney < 1000) {
return 2
}
return 3
}
const strategy = () => { // 订单类型+环境类型策略
const map = new Map([
[{
orderType: 1,
orderWay: 1,
orderMoney: 1
}, () => {
console.log('美妆订单h5-0')
}],
[{
orderType: 1,
orderWay: 1,
orderMoney: 2
}, () => {
console.log('美妆订单h5-100')
}],
[{
orderType: 1,
orderWay: 1,
orderMoney: 3
}, () => {
console.log('美妆订单h5-1000')
}],
])
return map
}
const run = (orderType, orderWay, orderMoney) => {
let action = [...strategy()].filter(([key, value]) => (key.orderType === orderType && key.orderWay === orderWay && key.orderMoney === orderMoney))
action.forEach(([key, value]) => value.call(this))
}
run(orderType, orderWay, orderMoneyStrategy(orderMoney))
上述就是将两个策略拆开再组合，可以使条件逻辑更加清晰，但是从上述例子也能看出，策略模式在使用过程中并不能减少很多的代码量，并且策略越多，拆分组合的过程就会越复杂，所以的使用过程中要合理运用。
附加信息
完整的 demo 地址：项目实战 demo，喜欢的朋友可以 star 一下，后续会根据设计模式博文的推出，逐步的将此项目继续拓展出来。
