职责链模式的定义是:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。
职责链模式的名字非常形象,一系列可能会处理请求的对象被连接成一条链,请求在这些对象之间依次传递,直到遇到一个可以处理它的对象,我们把这些对象称为链中的节点。
一、实际开发中的职责链模式
假设我们负责一个售卖手机的电商网站,经过分别交纳500 元定金和200 元定金的两轮预定后(订单已在此时生成),现在已经到了正式购买的阶段。
公司针对支付过定金的用户有一定的优惠政策。在正式购买后,已经支付过500 元定金的用户会收到100 元的商城优惠券,200 元定金的用户可以收到50 元的优惠券,而之前没有支付定金的用户只能进入普通购买模式,也就是没有优惠券,且在库存有限的情况下不一定保证能买到。
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 优惠券
二、用职责链模式重构代码
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 元定金预购, 得到500 优惠券 order500( 3, false, 500 ); // 输出:普通购买, 无优惠券 order500( 3, false, 0 ); // 输出:手机库存不足
这依然是违反开放封闭原则的,如果有天我们要增加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,表示在链中的下一个节点。
// Chain.prototype.setNextSuccessor 指定在链中的下一个节点 // Chain.prototype.passRequest 传递请求给某个节点 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( 2, true, 500 ); // 输出:200 元定金预购,得到50 优惠券 chainOrder500.passRequest( 3, true, 500 ); // 输出:普通购买,无优惠券 chainOrder500.passRequest( 1, false, 0 ); // 输出:手机库存不足
四、职责链模式的优缺点
职责链模式的最大优点就是解耦了请求发送者和N 个接收者之间的复杂关系,由于不知道链中的哪个节点可以处理你发出的请求,所以你只需把请求传递给第一个节点即可。用了职责链模式之后,每种订单都有各自的处理函数而互不影响。
其次,使用了职责链模式之后,链中的节点对象可以灵活地拆分重组。增加或者删除一个节点,或者改变节点在链中的位置都是轻而易举的事情。
职责链模式还有一个优点,那就是可以手动指定起始节点,请求并不是非得从链中的第一个节点开始传递。
这种模式也并非没有弊端,首先我们不能保证某个请求一定会被链中的节点处理。比如在期末考试的例子中,小纸条上的题目也许没有任何一个同学知道如何解答,此时的请求就得不到答复,而是径直从链尾离开,或者抛出一个错误异常。在这种情况下,我们可以在链尾增加一个保底的接受者节点来处理这种即将离开链尾的请求。
另外,职责链模式使得程序中多了一些节点对象,可能在某一次的请求传递过程中,大部分节点并没有起到实质性的作用,它们的作用仅仅是让请求传递下去,从性能方面考虑,我们要避免过长的职责链带来的性能损耗。
五、用 AOP 实现职责链
改写一下Function.prototype.after 函数,使得第一个函数返回'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( 2, true, 500 ); // 输出:200 元定金预购,得到50 优惠券 order( 1, false, 500 ); // 输出:普通购买,无优惠券
用AOP 来实现职责链既简单又巧妙,但这种把函数叠在一起的方式,同时也叠加了函数的作用域,如果链条太长的话,也会对性能有较大的影响。
六、用职责链模式获取文件上传对象
之前有一个用迭代器获取文件上传对象的例子:当时我们创建了一个迭代器来迭代获取合适的文件上传对象,其实用职责链模式可以更简单,我们完全不用创建这个多余的迭代器。
var getActiveUploadObj = function(){ try{ return new ActiveXObject("TXFTNActiveX.FTNUpload"); // IE 上传控件 }catch(e){ return 'nextSuccessor' ; } }; var getFlashUploadObj = function(){ if ( supportFlash() ){ var str = '<object type="application/x-shockwave-flash"></object>'; return $( str ).appendTo( $('body') ); } return 'nextSuccessor' ; }; var getFormUpladObj = function(){ return $( '<form><input name="file" type="file"/></form>' ).appendTo( $('body') ); }; 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 getUploadObj = getActiveUploadObj.after( getFlashUploadObj ).after( getFormUpladObj ); console.log( getUploadObj() );