js常用设计模式1-单例模式
js常用设计模式2-策略模式
js常用设计模式3-代理模式
js常用设计模式4-发布-订阅模式
js常用设计模式5-命令模式
js常用设计模式6-组合模式
js常用设计模式7-享元模式
js常用设计模式8-职责链模式
js常用设计模式9-中介者模式
js常用设计模式10-装饰者模式
js常用设计模式11-状态模式
职责链模式：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之前的耦合关系，将这些对象连成一条链，并沿着这条链传递该请求，知道又一个对象处理它为止。
1，现实中的职责链模式
公交车上人很多的时候，把卡给前面的人，一个一个往前递过去，最后刷卡
2，实际开发中的职责链模式
现在我们负责一个手机商城，客户可以选择交500元定金或者200元定金，也可以不交，现在到了正式购买阶段。
优惠：
- 500定金，得到100元优惠券
- 200定金，得到50元优惠券
- 无定金，普通购买模式，无优惠券
字段： - orderType：订单类型（定金购买或者普通用户购买），1：500元定金，2：200元定金，3：无定金
- pay：用户是否已经支付定金，值为true或false。如果用户下过500元定金的订单，但是没有付款，则会降级为普通购买模式
- stock：普通购买的手机库存，200元和500元的定金购买不在此列
代码：
var order = function (orderType, pay, stock) {
if (orderType === 1) {
if (pay === true) {
console.log('500元定金预购，得到100元优惠券')
} else {
if (stock > 0) {
console.log('库存足够，普通购买')
} else {
console.log('库存不足，无法购买')
}
}
} else if (orderType === 2) {
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, 300)
3，用职责链模式重构代码
现在我们用职责链模式重构这段代码。
将之前的函数拆分成分别处理500元定金、200元定金、无定金的三个函数。
先把orderType、pay、stock这三个参数传给函数500，如果不符合条件，则传递向函数200，最后不行就传给函数0
/**
* 稍作修改，第一级别职责链模式
* 问题：请求传递的代码和业务逻辑代码耦合严重，违反开放-封闭原则
*/
var order500 = function (orderType, pay, stock) {
if (orderType === 1 && pay === true) {
console.log('500元定金预购，得到100元优惠券')
} else {
order200(orderType, pay, stock)
}
}
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, 300)
order500(2, true, 300)
order500(1, true, 0)
order500(3, false, 0)
但是现在的代码耦合很严重，因为里面是严重的依赖关系，比如：
var order500 = function (orderType, pay, stock) {
if (orderType === 1 && pay === true) {
console.log('500元定金预购，得到100元优惠券')
} else {
order200(orderType, pay, stock)
}
}
order500处理不了的要交给order200，但是如果有一天中间需要添加一个order300呢？想一想还是个很麻烦的事，有什么办法可以很好地解决这个问题呢？
4，职责链优化
我们现在需要的是灵活可拆分的职责链节点。
（1）首先，要改写不符合要求时的情况，不要指定某一个固定的函数，而是返回一个特定的字符串“next”：
var order500 = function (orderType, pay, stock) {
if (orderType === 1 && pay === true) {
console.log('500元定金预购，得到100元优惠券')
} else {
return 'next'
}
}
var order200 = function (orderType, pay, stock) {
if (orderType === 2 && pay === true) {
console.log('200元定金预购，得到50元优惠券')
} else {
return 'next'
}
}
var orderNormal = function (orderType, pay, stock) {
if (stock > 0) {
console.log('库存足够，普通购买')
} else {
console.log('库存不足，无法购买')
}
}
（2）写职责链节点的构造函数，将order函数包装进去：
定义构造函数Chain，new Chain的时候传入上面创建的order函数，同时里面还有一个nextFn，表示在链中的下一个节点
// 创建一个新的类，用于提供给用户实现自定义的业务逻辑
var Chain = function (fn) {
this.fn = fn
this.nextFn = null
}
Chain.prototype.setNextFn = function (nextFn) {
//此处可以实现链式调用
return this.nextFn = nextFn
}
Chain.prototype.request = function () {
var result = this.fn.apply(this, arguments)
//不可以用这种写法
// var result = this.fn(arguments)
if (result === 'next') {
return this.nextFn && this.nextFn.request.apply(this.nextFn, arguments)
}
return result
}
（3）创建节点，设置依赖顺序，最后执行demo
var chainOrder500 = new Chain(order500)
var chainOrder200 = new Chain(order200)
var chainOrderNormal = new Chain(orderNormal)
chainOrder500.setNextFn(chainOrder200).setNextFn(chainOrderNormal)
chainOrder500.request(2, true, 300)
5，异步的职责链
有时候会有ajax这种异步请求，这时候如果要等到结果返回才能继续执行程序，就没啥用了
这时候同步返回的’next‘就没用了，对于result，总是undefined
需要新的函数next，手动传递请求给职责链中的下一个节点：
Chain.prototype.next = function () {
return this.nextFn && this.nextFn.request.apply(this.nextFn, arguments)
}
试试效果：
var f1 = new Chain(function () {
console.log('f1')
return 'next'
})
var f2 = new Chain(function () {
console.log('f2')
var self = this
setTimeout(function () {
self.next()
}, 1000);
})
var f3 = new Chain(function () {
console.log('f3')
})
f1.setNextFn(f2).setNextFn(f3)
f1.request()
6，职责链的优缺点
优点：
（1）解耦，只需要第一个函数处理问题就行，不要再管以前那种一堆的分支语句了
（2）可以灵活拆分，增加或者删除节点都很简单
（3）可以手动定位起点，不一定非要从order500开始，order300也不错啊。但是分支语句就不行，我们不能越过某个if判断
缺点：
（1）可能最后没有函数能受理接收到的情况，因此需要一个保底函数
（2）代码变复杂了，多了节点构造函数和节点对象，在一次运行中可能不起作用，性能会差一点
