职责链模式的定义是:使多个对象都有机会处理请求,从而避免请求的发送者和接受者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,知道有一个对象处理它为止。html
职责链模式的名字很是形象,一系列可能会处理请求的对象被链接成一条链,请求在这些对象之间依次传递,直到遇到一个能够处理它的对象,咱们把这些对象称为链中的节点,如图所示:程序员
职责链模式的例子在现实中并不难找到,如下就是两个常见的跟职责链模式有关的场景。ajax
从这两个例子中,咱们很容易找到职责链模式的最大优势:请求发送者只须要知道链中的第一个节点,从而弱化了发送者和一组接收者之间的强联系。若是不使用职责链模式,那么在公交车上,咱们就得先搞清楚谁是售票员,才能把硬币递给他。一样,在期末考试中,也许我就要先了解同窗中有哪些能够解答这道题。设计模式
假设咱们负责一个售卖手机的电商网站,通过分别交纳 500 元定金和 200 元定金的两轮预订后(订单已在此时生成),如今已经到了正式购买的阶段。app
公司针对支付过定金的用户有必定的优惠政策。在正式购买后,已经支付过 500 元定金的用户会收到 100 元的商城优惠券, 200 元定金的用户能够收到 50 元的优惠券,而以前没有支付定金的用户只能进入普通购买模式,也就是没有优惠券,且在库存有限的状况下不必定保证能买到。框架
咱们的订单页面是 PHP 吐出的模板,在页面加载之初, PHP 会传递给页面几个字段。异步
下面咱们把这个流程写成代码:函数
var 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 元订单 var order500 = function (orderType, pay, stock) { if (orderType === 1 && pay === true) { console.log(' 500 元定金预购,获得 100 优惠券'); } else { order200(orderType, pay, stock); //将请求传递给 200 元订单 } }; // 200 元订单 var order200 = function (orderType, pay, stock) { if (orderType === 2 && pay === true) { console.log(' 200 元定金预购,获得 50 优惠券'); } else { orderNormal(orderType, pay, stock); //将请求传递给普通订单 } }; // 普通订单 var 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 元定金预购,获得 50 优惠券 order500(3, false, 500) //输出:普通购买,无优惠券
能够看到,执行结果和前面那个巨大的 order 函数彻底同样,可是代码的结构已经清晰了不少,咱们把一个大函数拆分了 3 个小函数,去掉了许多嵌套的条件分支语句。
目前已经有了不小的进步,但咱们不会知足于此,虽然已经把大函数拆分红了互不影响的 3 个小函数,但能够看到,请求在链条中的顺序很是僵硬,传递请求的代码被耦合在了业务函数之中:
var order500 = function (orderType, pay, stock) { if (orderType === 1 && pay === true) { console.log(' 500 元定金预购,获得 100 优惠券'); } else { order200(orderType, pay, stock); // order200 和 order 500 耦合在一块儿 } };
这依然是违反开放——封闭原则的,若是有天咱们要增长 300 元预订或者去掉 200 元预订,意味着就必须改动这些业务函数内部。就像一根环环相扣打了死结的链条,若是要增长,拆除或者移动一个节点,就必须得先砸烂这根链条。
本节咱们采用一种更灵活的方式,来改进上面的职责链模式,目标是让链中的各个节点能够灵活拆分和重组。
首先须要改写一下分别表示 3 种购买模式的节点函数,咱们约定,若是某个节点不能处理请求,则返回一个特定的字符串 ‘nextSuccessor’ 来表示该请求须要继续日后传递:
var order500 = function (orderType, pay, stock) { if (orderType === 1 && pay === true) { console.log(' 500 元定金预购,获得 100 优惠券'); } else { return 'nextSuccessor'; //我不知道下一个节点是谁,反正把请求日后面传递 } }; var order200 = function (orderType, pay, stock) { if (orderType === 2 && pay === true) { console.log(' 200 元定金预购,获得 50 优惠券'); } else { return 'nextSuccessor'; //我不知道下一个节点是谁,反正把请求日后面传递 } }; var orderNormal = function (orderType, pay, stock) { if (stock > 0) { console.log('普通购买,无优惠券'); } else { console.log('手机库存不足'); } }
接下来须要把函数包装进职责链节点,咱们定义一个构造函数 Chain ,在 new Chain 的时候传递的参数即为须要被包装的函数,同时它还拥有一个实例属性 this.successor ,表示在链中的下一个节点。
var Chain = function (fn) { this.fn = fn; this.successor = null; }; //指定在链中的下一个节点 Chain.prototype.setNextSuccessor = function (successor) { return this.successor = successor; } //传递请求给某个节点 Chain.prototype.passRequest = function () { var ret = this.fn.apply(this, arguments); if (ret === 'nextSuccessor') { return this.successor && this.successor.passRequest.apply(this.successor, arguments); } return ret; }
如今咱们把 3 个订单函数分别包装成职责链的节点:
var chainOrder500 = new Chain(order500); var chainOrder200 = new Chain(order200); var chainOrderNormal = new Chain(orderNormal);
而后指定节点在职责链中的顺序:
chainOrder500.setNextSuccessor(chainOrder200); chainOrder200.setNextSuccessor(chainOrderNormal);
最后把请求传递给第一个节点:
chainOrder500.passRequest(1, true, 500); //输出: 500 元定金预购,获得 100 优惠券 chainOrder500.passRequest(1, false, 500); //输出:普通购买,无优惠券 chainOrder500.passRequest(2, true, 500); //输出: 200 元定金预购,获得 50 优惠券 chainOrder500.passRequest(3, false, 0); //输出:手机库存不足
经过改进,咱们能够自由灵活地增长,移除和修改链中的节点顺序,假如某天网站运营人员又想出了支持 300 元定金购买,那咱们就在该链中增长一个节点便可:
var order300 = function () { //具体功能略 } chainOrder300 = new Chain(order300); chainOrder500.setNextSuccessor(chainOrder300); chainOrder300.setNextSuccessor(chainOrder200);
对于程序员来讲,咱们老是喜欢去改动那些相对容易改动的地方,就像改动框架的配置文件远比改动框架的源代码简单得多。在这里彻底不用理会原来的订单函数代码,咱们要作的只是增长一个节点,而后从新设置链中相关节点的顺序。
在上一节的职责链模式中,咱们让每一个节点函数同步返回一个特定的值 “nextSuccessor” ,来表示是否把请求传递给下一个节点。而在现实开发中,咱们常常会遇到一些异步的问题,好比咱们要在节点函数中发起一个 ajax 异步请求,异步请求返回的结果才能决定是否继续在职责链中 passRequest。
这时候让节点函数同步返回 “nextSuccessor” 已经没有意义了,因此要给 Chain 类再增长一个原型方法 Chain.prototype.next ,表示手动传递请求给职责链中的下一个节点:
Chain.prototype.next = function () { return this.successor && this.successor.passRequest.apply(this.successor, arguments); }
来看一个异步职责链的例子:
var fn1 = new Chain(function () { console.log('1'); return 'nextSuccessor'; }); var fn2 = new Chain(function () { console.log('2'); var self = this; setTimeout(function () { self.next(); }, 1000); }); var fn3 = new Chain(function () { console.log('3'); }); fn1.setNextSuccessor(fn2).setNextSuccessor(fn3); fn1.passRequest();
如今咱们获得了一个特殊的链条,请求在链中的节点里传递,但节点有权力决定何时把请求交给下一个节点。能够想象,异步的职责链加上命令模式(把 ajax 请求封装成命令模式),咱们能够很方便地建立一个异步 ajax 队列库。
前面已经说过,职责链模式最大优势就是解耦了请求发送者和 N 个接收者之间的复杂关系,因为不知道链中的哪一个节点能够处理你发出的请求,因此你只须要传递给第一个节点便可。
在手机商城的例子中,原本咱们要被迫维护一个充斥着条件分支语句的巨大函数,在例子里的购买过程当中只打印了一条 log 语句。其实在现实开发中,这里要作更多事情,好比根据订单种类弹出不一样的浮层提示,渲染不一样的 UI 节点,组合不一样的参数发送给不一样的 cgi 等。用了职责链模式以后,每种订单都有各自的处理函数而互不影响。
其次,使用了职责链模式以后,链中的节点对象能够灵活地拆分重组。增长或者删除一个节点,或者改变节点在链中的位置都是垂手可得的事情。这一点咱们也已经看到,在上面的例子中,增长一种订单彻底不须要改动其余订单函数中的代码。
职责链模式还有一个优势,那就是能够手动指定起始节点,请求并非非得从链中的第一个节点开始传递。好比在公交车的例子中,若是我明确在我前面的第一我的不是售票员,那我固然能够越过他把公交卡递给他前面的人,这样就能够减小请求在链中的传递次数,更快的找到合适的请求接受者。这在普通的条件分支语句是作不到的,咱们没有办法让请求越过某一个 if 判断。
拿代码来证实这一点,假设某一天网站中支付过定金的订单已经所有结束购买流程,咱们接下来的时间里只须要处理普通购买订单,因此咱们能够直接把请求交给普通购买订单节点:
orderNormal.passRequest(1, false, 500); //普通购买,无优惠券
若是运用得当,职责链模式能够很好地帮助咱们组织代码,但这种模式也并不是没有弊端,首先咱们不能保证某个请求必定会被链中的节点处理。好比在期末考试的例子中,小纸条上的题目也许没有任何一个同窗知道如何解答,此时的请求就得不到答复,而是径直从链尾离开,或者抛出一个错误异常。在这种状况下,咱们能够在链尾增长一个保底的接受者来处理这种即将离开链尾的请求。
另外,职责链模式使得程序中多了一些节点对象,可能在某一次的请求传递过程当中,大部分节点并无起到实质性的做用,它们的做用仅仅是让请求传递下去,从性能方面考虑,咱们要避免过长的职责链带来的性能损耗。
在以前的职责链实现中,咱们利用了一个 Chain 类来把普通函数包装成职责链的节点。其实利用 JavaScript 的函数式特性,有一种更加方便的方法来建立职责链。
下面咱们建立一个 Function.prototype.after 函数,使得第一个函数返回 ‘nextSuccessor’ 时,将请求继续传递给下一个函数,不管是返回字符串 ‘nextSuccessor’ 或者 false 都只是一个约定,固然在这里咱们也可让函数返回 false 表示传递请求,选择 ‘nextSuccessor’ 字符串是由于它看起来更能表达咱们的目的,代码以下:
var order500 = function (orderType, pay, stock) { if (orderType === 1 && pay === true) { console.log(' 500 元定金预购,获得 100 优惠券'); } else { return 'nextSuccessor'; } }; var order200 = function (orderType, pay, stock) { if (orderType === 2 && pay === true) { console.log(' 200 元定金预购,获得 50 优惠券'); } else { return 'nextSuccessor'; } }; var orderNormal = function (orderType, pay, stock) { if (stock > 0) { console.log('普通购买,无优惠券'); } else { console.log('手机库存不足'); } } Function.prototype.after = function (fn) { var self = this; return function () { var ret = self.apply(this, arguments); if (ret === 'nextSuccessor') { return fn.apply(this, arguments); } return ret; }; }; var order = order500.after(order200).after(orderNormal); order(1, true, 500); //输出: 500 元定金预购,获得 100 优惠券 order(1, false, 500); //输出:普通购买,无优惠券 order(2, true, 500); //输出: 200 元定金预购,获得 50 优惠券 order(3, false, 0); //输出:手机库存不足
用 AOP 来实现职责链既简单又巧妙,但这种把函数叠在一块儿的方式,同时也叠加了函数的做用域,若是链条太长的话,也会对性能有较大的影响。
在 JavaScript 开发中,职责链模式是最容易被忽视的模式之一。实际上只要运用的当,职责链模式能够很好地帮助咱们管理代码,下降发起请求的对象和处理请求的对象之间的耦合性。职责链模式的节点数量和顺序是能够自由变化的,咱们能够在运行时决定链中包含哪些节点。
不管是做用域链,原型链,仍是 DOM 节点中的事件冒泡,咱们都能从中找到职责链模式的影子。职责链模式还能够和组合模式结合在一块儿,用来链接部件和父部件,或是提升组合对象的效率。学会使用职责链模式,相信在之后的代码编写中,将会对你大有裨益。
参考书目:《JavaScript设计模式与开发实践》