职责链模式

摘自《JavaScript设计模式与开发实践》

职责链模式的定义是：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

职责链模式的名字非常形象，一系列可能会处理请求的对象被连接成一条链，请求在这些对象之间依次传递，直到遇到一个可以处理它的对象，我们把这些对象称为链中的节点。

现实中的职责链模式

如果早高峰能顺利挤上公交车的话，那么估计这一天都会过得很开心。因为公交车上人实在太多了，经常上车后却找不到售票员在哪，所以只好把两块钱硬币往前面递。除非你运气够好，站在你前面的第一个人就是售票员，否则，你的硬币通常要在 N 个人手上传递，才能最终到达售票员的手里。

实际开发中的职责链模式

假设我们负责一个售卖手机的电商网站，经过分别交纳 500元定金和 200元定金的两轮预定后（订单已在此时生成），现在已经到了正式购买的阶段。

公司针对支付过定金的用户有一定的优惠政策。在正式购买后，已经支付过 500元定金的用户会收到 100元的商城优惠券，200元定金的用户可以收到 50元的优惠券，而之前没有支付定金的用户只能进入普通购买模式，也就是没有优惠券，且在库存有限的情况下不一定保证能买到。

orderType ：表示订单类型（定金用户或者普通购买用户）， code 的值为 1的时候是 500元定金用户，为 2的时候是 200元定金用户，为 3的时候是普通购买用户。
pay ：表示用户是否已经支付定金，值为 true 或者 false , 虽然用户已经下过 500元定金的订单，但如果他一直没有支付定金，现在只能降级进入普通购买模式。
stock ：表示当前用于普通购买的手机库存数量，已经支付过 500 元或者 200 元定金的用户不受此限制。

  const order = function (orderType, pay, stock) {
    if (orderType === 1) { // 500 元定金购买模式
      if (pay === true) { // 已支付定金
        console.log('500 元定金预购, 得到 100 优惠券')
      } else { // 未支付定金，降级到普通购买模式
        if (stock > 0) { // 用于普通购买的手机还有库存
          console.log('普通购买, 无优惠券')
        } else {
          console.log('手机库存不足')
        }
      }
    }
    else if (orderType === 2) { // 200 元定金购买模式
      if (pay === true) {
        console.log('200 元定金预购, 得到 50 优惠券')
      } else {
        if (stock > 0) {
          console.log('普通购买, 无优惠券')
        } else {
          console.log('手机库存不足')
        }
      }
    }
    else if (orderType === 3) {
      if (stock > 0) {
        console.log('普通购买, 无优惠券')
      } else {
        console.log('手机库存不足')
      }
    }
  }
  order(1, true, 500) // 输出： 500 元定金预购, 得到 100 优惠券

虽然我们得到了意料中的运行结果，但这远远算不上一段值得夸奖的代码。 order 函数不仅巨大到难以阅读，而且需要经常进行修改。虽然目前项目能正常运行，但接下来的维护工作无疑是个梦魇。

用职责链模式重构代码

现在我们采用职责链模式重构这段代码，先把 500 元订单、200 元订单以及普通购买分成 3个函数。接下来把 orderType 、 pay 、 stock 这 3个字段当作参数传递给 500元订单函数，如果该函数不符合处理条件，则把这个请求传递给后面的 200元订单函数，如果 200元订单函数依然不能处理该请求，则继续传递请求给普通购买函数，代码如下：

  // 500元订单
  const order500 = function (orderType, pay, stock) {
    if (orderType === 1 && pay === true) {
      console.log('500 元定金预购, 得到 100 优惠券')
    } else {
      order200(orderType, pay, stock) // 将请求传递给 200 元订单
    }
  }

  // 200元订单
  const order200 = function (orderType, pay, stock) {
    if (orderType === 2 && pay === true) {
      console.log('200 元定金预购, 得到 50 优惠券')
    } else {
      orderNormal(orderType, pay, stock) // 将请求传递给普通订单
    }
  }

  // 普通购买订单
  const orderNormal = function (orderType, pay, stock) {
    if (stock > 0) {
      console.log('普通购买, 无优惠券')
    } else {
      console.log('手机库存不足')
    }
  }
  order500(1, true, 500) // 输出：500 元定金预购, 得到 100 优惠券
  order500(1, false, 500) // 输出：普通购买, 无优惠券
  order500(2, true, 500) // 输出：200 元定金预购, 得到 500 优惠券
  order500(3, false, 500) // 输出：普通购买, 无优惠券
  order500(3, false, 0) // 输出：手机库存不足

可以看到，执行结果和前面那个巨大的 order 函数完全一样，但是代码的结构已经清晰了很多，我们把一个大函数拆分了 3个小函数，去掉了许多嵌套的条件分支语句。

目前已经有了不小的进步，但我们不会满足于此，虽然已经把大函数拆分成了互不影响的 3个小函数，但可以看到，请求在链条传递中的顺序非常僵硬，传递请求的代码被耦合在了业务函数之中：

  const order500 = function (orderType, pay, stock) {
    if (orderType === 1 && pay === true) {
      console.log('500 元定金预购, 得到 100 优惠券')
    } else {
      order200(orderType, pay, stock) // 将请求传递给 200 元订单
    }
  }

这依然是违反开放封闭原则的，如果有天我们要增加300 元预订或者去掉 200 元预订，意味着就必须改动这些业务函数内部。就像一根环环相扣打了死结的链条，如果要增加、拆除或者移动一个节点，就必须得先砸烂这根链条。

灵活可拆分的职责链节点

本节我们采用一种更灵活的方式，来改进上面的职责链模式，目标是让链中的各个节点可以灵活拆分和重组。

首先需要改写一下分别表示 3种购买模式的节点函数，我们约定，如果某个节点不能处理请求，则返回一个特定的字符串 'nextSuccessor' 来表示该请求需要继续往后面传递：

  // 我们约定，如果某个节点不能处理请求，则返回一个特定的字符串  'nextSuccessor' 来表示该请求需要继续往后面传递
  const order500 = function (orderType, pay, stock) {
    if (orderType === 1 && pay === true) {
      console.log('500 元定金预购，得到 100 优惠券')
    } else {
      return 'nextSuccessor' // 我不知道下一个节点是谁，反正把请求往后面传递
    }
  }
  const order200 = function (orderType, pay, stock) {
    if (orderType === 2 && pay === true) {
      console.log('200 元定金预购，得到 50 优惠券')
    } else {
      return 'nextSuccessor' // 我不知道下一个节点是谁，反正把请求往后面传递
    }
  }
  const orderNormal = function (orderType, pay, stock) {
    if (stock > 0) {
      console.log('普通购买，无优惠券')
    } else {
      console.log('手机库存不足')
    }
  }

接下来需要把函数包装进职责链节点，我们定义一个构造函数 Chain ，在 new Chain 的时候传递的参数即为需要被包装的函数，同时它还拥有一个实例属性this.successor ，表示在链中的下一个节点。此外 Chain 的 prototype 中还有两个函数，它们的作用如下所示：

  // Chain.prototype.setNextSuccessor 指定在链中的下一个节点
  // Chain.prototype.passRequest 传递请求给某个节点

  const Chain = function (fn) {
    this.fn = fn
    this.successor = null
  }
  Chain.prototype.setNextSuccessor = function (successor) {
    return this.successor = successor
  }
  Chain.prototype.passRequest = function () {
    const ret = this.fn.apply(this, arguments)
    if (ret === 'nextSuccessor') {
      return this.successor && this.successor.passRequest.apply(this.successor, arguments)
    }
    return ret
  }

现在我们把 3个订单函数分别包装成职责链的节点：

  const chainOrder500 = new Chain(order500)
  const chainOrder200 = new Chain(order200)
  const chainOrderNormal = new Chain(orderNormal)

然后指定节点在职责链中的顺序：

 chainOrder500.setNextSuccessor(chainOrder200)
 chainOrder200.setNextSuccessor(chainOrderNormal)

最后把请求传递给第一个节点：

  chainOrder500.passRequest(1, true, 500) // 输出：500 元定金预购，得到 100 优惠券
  chainOrder500.passRequest(2, true, 500) // 输出：200 元定金预购，得到 50 优惠券
  chainOrder500.passRequest(3, true, 500) // 输出：普通购买，无优惠券
  chainOrder500.passRequest(1, false, 0)  // 输出：手机库存不足

异步的职责链

<script>
  function Fn1() {
    console.log(1)
    return "nextSuccessor"
  }

  function Fn2() {
    console.log(2)
    const self = this
    setTimeout(function () {
      self.next()
    }, 1000)
  }

  function Fn3() {
    console.log(3)
  }

  // 下面需要编写职责链模式的封装构造函数方法
  const Chain = function (fn) {
    this.fn = fn
    this.successor = null
  }
  Chain.prototype.setNextSuccessor = function (successor) {
    return this.successor = successor
  }
  // 把请求往下传递
  Chain.prototype.passRequest = function () {
    const ret = this.fn.apply(this, arguments)
    if (ret === 'nextSuccessor') {
      return this.successor && this.successor.passRequest.apply(this.successor, arguments)
    }
    return ret
  }
  Chain.prototype.next = function () {
    return this.successor && this.successor.passRequest.apply(this.successor, arguments)
  }

  //现在我们把3个函数分别包装成职责链节点：
  const chainFn1 = new Chain(Fn1)
  const chainFn2 = new Chain(Fn2)
  const chainFn3 = new Chain(Fn3)

  // 然后指定节点在职责链中的顺序
  chainFn1.setNextSuccessor(chainFn2)
  chainFn2.setNextSuccessor(chainFn3)

  chainFn1.passRequest()  // 打印出1，2 过1秒后 会打印出3
</script>

调用函数 chainFn1.passRequest() 后，会先执行发送者Fn1这个函数打印出 1，然后返回字符串 nextSuccessor 接着就执行return this.successor && this.successor.passRequest.apply(this.successor,arguments) 这个函数到 Fn2，打印 2，接着里面有一个setTimeout 定时器异步函数，需要把请求给职责链中的下一个节点，因此过一秒后会打印出 3。

职责链的优缺点

职责链模式的优点是：

解耦了请求发送者和N个接收者之间的复杂关系，不需要知道链中那个节点能处理你的请求，所以你只需要把请求传递到第一个节点即可。
链中的节点对象可以灵活地拆分重组，增加或删除一个节点，或者改变节点的位置都是很简单的事情。
我们还可以手动指定节点的起始位置，并不是说非得要从其实节点开始传递的。

职责链模式的缺点是：

职责链模式中多了一点节点对象，可能在某一次请求过程中，大部分节点没有起到实质性作用，他们的作用只是让请求传递下去，从性能方面考虑，避免过长的职责链提高性能。