Go语言视频零基础入门到精通

五菱

一、引言
　　初看责任链模式，心里不禁想起了一个以前听过的相声：看牙。说的是一个病人看牙的时候，医生不小心把拔下的一个牙掉进了病人嗓子里。病人因此楼上楼下的跑了好多科室，最后无果而终。
　　责任链模式就是这种“推卸”责任的模式，你的问题在我这里能解决我就解决，不行就把你推给另一个对象。至于到底谁解决了这个问题了呢？我管呢！
　　二、定义与结构
　　从名字上大概也能猜出这个模式的大概模样——系统中将会存在多个有类似处理能力的对象。当一个请求触发后，请求将在这些对象组成的链条中传递，直到找到最合适的“责任”对象，并进行处理。
　　《设计模式》中给它的定义如下：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。
　　从定义上可以看出，责任链模式的提出是为了“解耦”，以应变系统需求的变更和不明确性。
　　下面是《设计模式》中给出的适用范围：
　　1) 有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
　　2) 你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
　　3) 可处理一个请求的对象集合应被动态指定。
　　责任链模式真的能给发送者和接收者之间解耦（这好像很神奇）吗？先来看下它的组成角色。这个问题我会在下面提及。
　　责任链模式由两个角色组成：
　　1) 抽象处理者角色（Handler）：它定义了一个处理请求的接口。当然对于链子的不同实现，也可以在这个角色中实现后继链。
　　2) 具体处理者角色（Concrete Handler）：实现抽象角色中定义的接口，并处理它所负责的请求。如果不能处理则访问它的后继者。
　　至于类图不放也罢。毕竟就是一个继承或者实现。
　　三、纯与不纯
　　责任链模式的纯与不纯的区别，就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用，满足系统需求并能很好的适应变化就好了。正所谓：管它黑猫白猫，抓住老鼠就是好猫！
　　纯的责任链模式，规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。
　　反之，则就是不纯的责任链模式。
　　不纯的责任链模式还算是责任链模式吗？比如一个请求被捕获后，每个具体处理者都尝试去处理它，不管结果如何都将请求再次转发。我认为这种方式的实现，算不算是责任链模式的一种倒不重要，重要的是我们也能从中体味到责任链模式的思想：通过将多个处理者之间建立联系，来达到请求与具体的某个处理者的解耦。
#############################################
三、纯与不纯
责任链模式的纯与不纯的区别，就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用，满足系统需求并能很好的适应变化就好了。正所谓：管它黑猫白猫，抓住老鼠就是好猫！
纯的责任链模式，规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。
反之，则就是不纯的责任链模式。
不纯的责任链模式还算是责任链模式吗？比如一个请求被捕获后，每个具体处理者都尝试去处理它，不管结果如何都将请求再次转发。我认为这种方式的实 现，算不算是责任链模式的一种倒不重要，重要的是我们也能从中体味到责任链模式的思想：通过将多个处理者之间建立联系，来达到请求与具体的某个处理者的解 耦。
举例：这个列子真他妈的简单易懂，我都已看就明白，
public interface Chain {
    public abstract void addChain(Chain c);
    public abstract void sendToChain(String mesg);
    public abstract Chain getChain();
}
public class Manager implements Chain {
    private Chain nextChain = null;
    private String responsibility = "Get Project";;

    public Manager() {
    }

    public void addChain(Chain c) {
        nextChain = c;
    }

    public Chain getChain() {
        return nextChain;
    }

    public void sendToChain(String mesg) {
        if(mesg.equals(responsibility)) {
            System.out.println("A manager --> Get a Project");
        } else {
            if(nextChain != null) {
                nextChain.sendToChain(mesg);
            }
        }
    }
   
}
public class ProjectManager implements Chain {
    private Chain nextChain = null;
    private String responsibility = "Design";
   
    public ProjectManager() {
    }
    public void addChain(Chain c) {
        nextChain = c;
    }
   
    public Chain getChain() {
        return nextChain;
    }
   
    public void sendToChain(String mesg) {
        if(mesg.equals(responsibility)) {
            System.out.println("A PM --> Design");
        } else {
            if(nextChain != null) {
                nextChain.sendToChain(mesg);
            }
        }
    }
   
}
public class Others implements Chain {
    private Chain nextChain = null;
    private String responsibility = "";
   
    public Others() {
    }
    public void addChain(Chain c) {
        nextChain = c;
    }
   
    public Chain getChain() {
        return nextChain;
    }
   
    public void sendToChain(String mesg) {
            System.out.println("No one can handle --> " + mesg);
    }
   
}
public class Test {
    public static void main(String[] args) {
        Manager aManager = new Manager();
        ProjectManager aPM = new ProjectManager();
        Others others = new Others();

        aManager.addChain(aPM);
        aPM.addChain(others);
        aManager.sendToChain("Get Project");
        aManager.sendToChain("Design");
        aManager.sendToChain("Coding");
        aManager.sendToChain("Test");
        aManager.sendToChain("Kill La Deng !");
    }
}
         把自己能解决的自己解决掉，自己不能解决的交给其它去解决，就这样一个传一个，不管最终谁解决了这个问题，降低耦合，
#############################################


　　下面的例子就是采用了上面提到的“不纯的责任链模式”。
　　四、举例
　　这个例子来源于项目中我刚刚完成的一个小功能点——“代号自动生成器”。在项目中存在很多地方，比如：员工工号、档案代号，要求客户在使用时输入。而这些代号对于一个特定的企业或者类别，往往有一定的规则。因此可以让用户在系统参数中维护一定的规则，然后通过“代号自动生成器”来给用户生成代号。
　　根据初期需求，用户代号中往往存在以下几种变动元素：年份、月份、日期、流水号。由于需求比较简单，因此考虑到用户可能存在其他变动元素，所以我打算在“被第一颗子弹击中”后重构一下现有的结构。下面就是我在头脑中演绎过的使用责任链模式的重构。
　　这里只用来说明下责任链模式的结构和使用，因此不体现功能细节。
//这是抽象处理者角色
public interface CodeAutoParse {
　//这里就是统一的处理请求使用的接口
　String[] generateCode(String moduleCode, int number, String rule,String[] target) throws BaseException;
}
//这个为处理日期使用的具体处理者
public class DateAutoParse implements CodeAutoParse{
　//获取当前时间
　private final Calendar currentDate = Calendar.getInstance();
　//这里用来注入下一个处理者，系统中采用的是Spring来管理的
　private CodeAutoParse theNextParseOfDate;
　public void setTheNextParseOfDate(CodeAutoParse theNextParseOfDate){
　　this.theNextParseOfDate = theNextParseOfDate ;
　}
　/*
　*实现的处理请求的接口
　*这个接口首先判断用户定义的格式是否有流水号,有则解析,没有则跳过
　*下传到下一个处理者
　*/
　public String[] generateCode(String moduleCode, int number, String rule, String[] target)
　　throws BaseException {
　　　//这里省略了处理的业务
　　　……
　　　if(theNextParseOfDate != null)
　　　　return theNextParseOfDate.generateCode(moduleCode , number , rule, target)
　　　else
　　　　return target;
　}
　　其它具体处理者也是如此的结构，每一个里面都设置有一个用来存放下一个处理者的引用，不管你有没有下一个处理者。
　　其实责任链模式本身的结构和使用都没有什么，就是一个继承或者实现。在处理请求的时候，按照规定去调用下一个处理者。但是怎么来维护这样一条链子呢？
　　《设计模式》一书中仅仅说必须自己引入它，可以参考使用list或者map来进行注册。而在上面我使用spring来管理具体处理者角色的引入。当有了新的处理者需要添加的时候，仅仅需要修改下配置文件。
　　五、其他
　　责任链模式优点，上面已经体现出来了。无非就是降低了耦合、提高了灵活性。但是责任链模式可能会带来一些额外的性能损耗，因为它要从链子开头开始遍历。