阅读 4606

前端设计模式之策略模式

前言

传送地址:

前端设计模式之工厂模式

前端设计模式之代理模式

设计模式已经到了第三篇,前两篇分别是代理模式与工厂模式,那么继续我们 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 排版

文章分类
前端