一周两个设计模式—设计模式之责任链模式（第五周）

业务场景：

“小犬，小犬，咖啡系统的预定流程需要优化一下。”，一大早，哮天犬就被手机从睡梦中叫醒接到了李天王的要求，“优化？这不是一直都
运行的很好吗？为什么要优化？凭什么优化？我已经把系统开发完了。”，为什么小犬子今天这么强硬呢，原来是上次说解决分店的问题后
就给小犬个编制，可是结果是问题解决完了，编制却没有信儿了，仔细一打听才知道是被牛郎给顶替了，所以小犬这次生气并且是很生气
的那种，因为这个编制的事情玉兔都差点和它分手了，能不生气吗？

“小犬啊，我知道上次的事情上面的人办的不地道。”，天王是多么狗的一个人啊，肯定知道今天小犬生气的原因。“可是，你也得知道，牛郎
和七仙女两个分居这么久了，并且人家的故事这么感人，都获得感动天庭的十大人物了，玉帝都不好意思了，所以老大下的命令占了一个名额，
不好运的轮到你了，这次只要解决了问题，下次评优肯定有你，我把三小子的名额给你。”，天王都说到这了还能有什么办法呢？老流程，
问原因和需求吧。

原来是咖啡预定系统的问题，现在是天庭咖啡厅有N个师傅，但是技术参差不齐，但是系统分订单的时候出问题，有些比较难的订单发给
新手师傅的手里了制作简单却分给大师手里了，好嘛，这样就出问题了，口感好的便宜，贵的口感很差，最近投诉都快顶不住了。

开始分析：

其实问题并不是很复杂，就是下订单到底是谁来接的问题，为每一笔订单设置一个权值，然后为每个师傅分配权值适用范围，例如新手
净坛使者只能接受权值小于5的订单，白龙马因为有了一定的经验可以接订单权值小于10的，而特邀技师弼马温可以接收小于60的，如果
难度大于60直接拒绝或者直接让玉帝来处理，这样是不是很清晰。

告诉我你们的第一反应是不是if else语句，这样肯定可以实现这个功能，但是有没有考虑到如果在细分呢，代码是不是很乱并且耦合度
太高、并且不易维护并且随着时间的推移，维护都是一个问题。怎么办呢，古话讲兵马未动粮草先行，作为技术大牛肯定得先思考怎么处理
，经过分析决定使用责任链模式了。

输入条件-》A处理如果不够权限-》B处理-》C处理-》D处理，其中有任何一个人处理就直接返回处理结果，就是结单。

有了明确的目的，下面就是实现了。

可以把制作咖啡分为四个级别 0—10、10—20、20—30、30—40。

然后开始实现，通过介绍肯定能想到，低级有高级别的引用，A里面肯定有B的引用，B里有C的引用。不多哔哔了，直接搞代码。

设计模式最主要的就是抽象：

抽象：

abstract class CoffeeOrder {

     var nextReceiver:CoffeeOrder ?= null  //下一级的引用，这里处理一下

     abstract fun receive(num:Int)  //具体实现的逻辑
}

具体实现类：

//只有实现，如果超过则下一级处理，第一级别
 class PigOrder:CoffeeOrder() {
    override fun receive(num: Int) {
        if(num<10){
            Log.v("=========","老猪处理了")
        }else{
            if(super.nextReceiver != null){
                super.nextReceiver?.receive(num)
            }else{
            Log.v("=========","老猪处理不了了")
            }
    }
  }
}

//第二级别
 class HorseOrder:CoffeeOrder() {
override fun receive(num: Int) {
    if(num<20){
        Log.v("=========","白龙马处理了")
    }else{
        if(super.nextReceiver != null){
            super.nextReceiver?.receive(num)
        }else{
            Log.v("=========","白龙马处理不了了")
        }
    }
}
}

依次类推，创建N个级别具体处理事件。

现在都创建出来了，如何引用呢？别着急，往下看。

sendOrderF = PigOrder()
sendOrderS = HorseOrder()
sendOrderT = MonkeyOrder()
sendOrderFO = BigOrder()
sendOrderT.nextReceiver = sendOrderFO
sendOrderS.nextReceiver = sendOrderT
sendOrderF.nextReceiver = sendOrderS

其实就是低一级引用高一级的实例，并且是顺序依赖，其实这个可以和创建者共同使用的，这样就完全抽离了。

哈哈，这一次的责任链就完事了，不对得总结一下：

优点

动态组合，使请求者和接受者解耦。

请求者和接受者松散耦合：请求者不需要知道接受者，也不需要知道如何处理。每个职责对象只负责自己的职责范围，
其他的交给后继者。

各个组件间完全解耦。

动态组合职责：职责链模式会把功能分散到单独的职责对象中，然后在使用时动态的组合形成链，从而可以灵活的分配职责对象，
也可以灵活的添加改变对象职责。

缺点

产生很多细粒度的对象：因为功能处理都分散到了单独的职责对象中，每个对象功能单一，要把整个流程处理完，需要
很多的职责对象，会产生大量的细粒度职责对象。

不一定能处理：每个职责对象都只负责自己的部分，这样就可以出现某个请求，即使把整个链走完，都没有职责对象处理它。
这就需要提供默认处理，并且注意构造链的有效性。

责任链模式在程序开发中的使用场景还是挺多的，主要适用于多个条件的筛选，例如部分需求在不同范围的想条件下需
要使用不同的处理方式但是总体的返回是没有变化的情况。