前端设计模式之策略模式

前言

传送地址：

设计模式已经到了第三篇，前两篇分别是代理模式与工厂模式，那么继续我们 23 篇设计模式的链路-策略模式。

策略模式

策略模式的定义与特点

策略（Strategy）模式的定义：该模式定义了一系列算法，并将每个算法封装起来，使它们可以相互替换，且算法的变化不会影响使用算法的客户。策略模式属于对象行为模式，它通过对算法进行封装，把使用算法的责任和算法的实现分割开来，并委派给不同的对象对这些算法进行管理。此什么是策略模式处引用了 gof 设计模式的描述。

策略模式的主要优点如下：

多重条件语句不易维护，而使用策略模式可以避免使用多重条件语句。
策略模式提供了一系列的可供重用的算法族，恰当使用继承可以把算法族的公共代码转移到父类里面，从而避免重复的代码。
策略模式可以提供相同行为的不同实现，客户可以根据不同时间或空间要求选择不同的。
策略模式提供了对开闭原则的完美支持，可以在不修改原代码的情况下，灵活增加新算法。
策略模式把算法的使用放到环境类中，而算法的实现移到具体策略类中，实现了二者的分离。

其主要缺点如下：

客户端必须理解所有策略算法的区别，以便适时选择恰当的算法类。
策略模式造成很多的策略类。

策略模式的通俗理解

接着我们宠物店的🌰，我们除了招代理商之外，还可以引入互联网的大数据分析得出我们定向推荐的客户类型，提高服务质量

客户描述	宠物推荐	宠物照片
儿童客户：主要推荐一些比较乖巧，攻击性不高的小型犬	柴犬
女性客户：主要推荐一些颜值较高的小型犬	萨摩耶，吉娃娃
头铁客户：主要推荐一些特别折腾的，真的勇士型宠物	哈士奇

上面的🌰都是单条件，然而在现实中的很多情况会复杂的多，比如客户会有跨越年龄、性别、生活习惯、家庭环境、个人性格等各种因素参杂在一快，所以用户行为画像是一个非常复杂而细致的事情，也导致我们在处理客户喜好的时候，会出现多重条件干扰因素，推荐算法会比较复杂。

项目实战

解决多重条件业务

多业务场景下的订单跳转一直是个很头疼的问题，因为每条业务的订单可能需要定制，跳转的详情也可能不太一样，当业务线过多的时候，很容易陷入多重条件地狱，不断去累加判断条件

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 一下，后续会根据设计模式博文的推出，逐步的将此项目继续拓展出来。

手动狗头镇楼

本文使用 mdnice 排版