职责链模式的定义是:使多个对象都有机会处理请求,从而避免请求的发送者和接收者之间的耦合关系,将这些对象连成一条链,并沿着这条链传递该请求,直到有一个对象处理它为止。在职责链中,请求发送者只需要知道链中的第一个节点就可以将请求一直传递下去,这样就弱化了发送者和一组接收者之间的强联系。
下面看一个购物订单处理的例子
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.aplly( this, arguments );
}
}
}
var order = order500yuan.after( order200yuan ).after( orderNormal );
order( 1, true, 500 ); //输出:500元定金预购,得到100元优惠券
函数的大概意思就是根据传入的参数区分你是哪种购物状态,这里面的关键就是Function.prototype.after方法了,他实现的功能比较强大,在运行了本身的函数后,根据函数结果决定,是否对作为参数传入的函数进行执行,当然由于他返回的还是函数,所以可以继续进行链式调用,而且节点的次序也就是他们执行的次序都是由你来决定的。
在这里需要注意的是,这样固然很好的管理了代码,将每个处理请求的函数都封装了起来,也降低了发送请求的对象和处理请求对象之间的耦合性,但是如果职责链链条太长了的话会对性能造成很大影响。
中介者模式
面向对象设计鼓励将行为分布到各个对象中,以便于不要出现特别庞大难以维护的对象,同时增加对象的可复用性,但是当对象数目多而且相互之间关系复杂的时候,他们的可复用性实际上是降低了,因为关系网错综复杂,往往牵一发而动全身,修改对象变得异常艰难。这时就轮到中介者出场了,有了中介者后,各个对象之间的联系全靠中介者进行传递,彼此之间并不互相引用,在当一个对象改变时,只需要通知中介者即可。这样一个网状的关系就变成了一个以中介者为中心的一对多的关系。
如果你在玩一个多人对战游戏,说不定中介者就是这样的
<span style="font-size:18px;">var player = function( name ){
this.name = name;
};
player.prototype.die = function(){
playerDirector.ReceiveMessage( 'playerDead', this );//通知中介者玩家阵亡
};
var playerDirector = function(){
//保存一系列接收.通知方法 如ReceiveMessage postMessage
};
var player1 = new player( 'tom' );
var player2 = new player( 'jack' );
var player3 = new player( 'lucy' );</span>
以上就是一个中介者的小原型吧,体会一下大概的意思就好,虽然很简单,但是还是体现出了最少知识原则,各个玩家之间直接联系很少,只能通过中介者进行传递,这样各个对象就得以解耦,不过中介者模式也存在相应缺点,最大的缺点是系统中会增加一个要维护的中介者对象,而且如果中介者对象非常庞大,那么维护起来会非常痛苦。所以还是那句话,因地制宜,根据开发中的实际情况衡量利弊选择是否采用中介者模式。