设计模式责任链模式（Chain of Responsibility Method)

问题：
在面向对象的设计中，经常会遇到有多个对象共同处理同一事件，但是各自对事件的处理权限却有不同的场合，一个比较简单的例子就是逐级审批，组长审批完成后，交给经理审批，经理审批完成交给总监，总监审批完给总裁...比较传统的解决办法就是，由客户端来判断，现在处于哪个阶段，下一步应调用哪个对象的方法，进入哪一个阶段，可是请求的发送者需要维护多个耦合，以处理请求信息的传达。这就存在请求的发送者与多个接收者之间是高耦合。

定义：
《设计模式》中给它的定义如下：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止

意图：
Chain of Responsibility模式中ConcreteHandler将自己的后继对象（向下传递消息的对象）记录在自己的后继表中，通过这样的连接，将可能处理一个请求的对象链接成一个链，当一个请求到来时，ConcreteHandler会先检查看自己有没有匹配的处理程序，如果有就自己处理，否则传递给它的后继。这使得发出这个请求的客户端并不需要知道链上的哪一个对象最终处理这个请求，避免了请求的发出者与接收者之间的高耦合，客户端只需组织其责任链，并且设置请求，并可以动态地重新组织和分配责任。

参与者：
抽象处理者(Handler)角色：定义出一个处理请求的接口。如果需要，接口可以定义出一个方法，以设定和返回对后继对象的引用。这个角色通常由一个抽象类或接口实现。
具体处理者(ConcreteHandler)角色：具体处理者接到请求后，可以选择将请求处理掉，或者将请求传给后继对象。由于具体处理者持有对后继对象的引用，因此，如果需要，具体处理者可以访问后继对象。 

UML:

纯与不纯：
责任链模式的纯与不纯的区别，就像黑猫、白猫的区别一样。不要刻意的去使自己的代码来符合一个模式的公式。只要能够使代码降低耦合、提高重用，满足系统需求并能很好的适应变化就好了。正所谓：管它黑猫白猫，抓住老鼠就是好猫！ 
纯的责任链模式，规定一个具体处理者角色只能对请求作出两种动作：自己处理；传给下家。不能出现处理了一部分，把剩下的传给了下家的情况。而且请求在责任链中必须被处理，而不能出现无果而终的结局。 
反之，则就是不纯的责任链模式。 
不纯的责任链模式还算是责任链模式吗？比如一个请求被捕获后，每个具体处理者都尝试去处理它，不管结果如何都将请求再次转发。我认为这种方式的实现，算不算是责任链模式的一种倒不重要，重要的是我们也能从中体味到责任链模式的思想：通过将多个处理者之间建立联系，来达到请求与具体的某个处理者的解耦。 

实例：

public abstract class Handler {
    protected Handler successor;
    protected String name;

    public String getName() {
        return name;
    }

    //处理请求，由子类完成 
    public abstract void handleRequest(String request);

    //设置下一个处理请求的人 
    public void setNextHandler(Handler successor) {
        this.successor = successor;
    }
}

public class LaoShi extends Handler{
    public LaoShi(String name) {
        this.name = name;
    }

    public void handleRequest(String request) {
        if ("请假不去上课".equals(request)) {
            System.out.println(name + "可以处理" + request + ",给予批准！");
        } else {
            System.out.println(name + "不可以处理" + request + "转交给"
                    + successor.getName());
            successor.handleRequest(request);
        }
    }

}
public class BanZhang extends Handler {
    public BanZhang(String name) {
        this.name = name;
    }

    public void handleRequest(String request) {
        if ("不去开班会".equals(request)) {
            System.out.println(name + "可以处理" + request + ",给予批准！");
        } else {
            System.out.println(name + "不可以处理" + request + "转交给"
                    + successor.getName());
            successor.handleRequest(request);
        }
    }
}


public class DaoYuan extends Handler {
    public DaoYuan(String name) {
        this.name = name;
    }

    public void handleRequest(String request) {
        if ("离校".equals(request)) {
            System.out.println(name + "可以处理" + request + "给于批准！");
        } else {
            System.out.println(name + "不可以处理" + request + "转交给"
                    + successor.getName());
            successor.handleRequest(request);
        }
    }
}

public class XiaoZhang extends Handler {
    public XiaoZhang(String name) {
        this.name = name;
    }

    public void handleRequest(String request) {
        if ("退学".equals(request)) {
            System.out.println(name + "可以处理" + request + "给于批准！");
        } else {
            System.out.println(name + "觉的" + request + "是无理请求，不给于批准");
        }
    }
}
public class XueYuan {
    private String name;

    public XueYuan(String name) {
        this.name = name;
    }

    public static void main(String[] args) {
        HandlerWithoutPattern banzhang = new HandlerWithoutPattern("班长");
        HandlerWithoutPattern daoyuan = new HandlerWithoutPattern("导员");
        HandlerWithoutPattern xiaozhang = new HandlerWithoutPattern("校长");
        //将请求给不同的人以便能够得到处理，因为客户程序不知道这些请求具体哪个 
        //人能够处理，于是它便把请求一一的交给处理者 
        banzhang.handleRequest("不去开班会");
        daoyuan.handleRequest("不去开班会");
        xiaozhang.handleRequest("不去开班会");

/*        banzhang.handleRequest("离校"); 
        daoyuan.handleRequest("离校"); 
        xiaozhang.handleRequest("离校"); 

        banzhang.handleRequest("退学"); 
        daoyuan.handleRequest("退学"); 
        xiaozhang.handleRequest("退学");  */ 
    }
}


    public class HandlerWithoutPattern {
    
        private String name; //处理者的名字 
        public HandlerWithoutPattern(String name) {
            this.name = name;
        }
        public void handleRequest(String request) {
            if ("班长".equals(name)) {
                if ("不去开班会".equals(request)) {
                    System.out.println(name + "可以处理" + request + ",给于批准");
                } else {
                    System.out.println(name + "不处理" + request + "这种请求");
                }
            } else if ("导员".equals(name)) {
                if ("离校".equals(request)) {
                    System.out.println(name + "可以处理" + request + ",给于批准");
                } else {
                    System.out.println(name + "不处理" + request + "这种请求");
                }
            } else if ("校长".equals(name)) {
                if ("退学".equals(request)) {
                    System.out.println(name + "可以处理" + request + ",给于批准");
                } else {
                    System.out.println(name + "不处理" + request + "这种请求");
                }
            } else {
                System.out.println("没有专人可以处理这个请求");
            }
    } 

}
public class XueYuanWithPattern {
    private String name;

    public XueYuanWithPattern(String name) {
        this.name = name;
    }

    public static void main(String[] args) {
        Handler banzhang = new BanZhang("班长");
        Handler laoshi = new BanZhang("老师");
        Handler daoyuan = new DaoYuan("导员");
        Handler xiaozhang = new XiaoZhang("校长");
        banzhang.setNextHandler(laoshi); // 设置班长的下一个处理者是老师
        laoshi.setNextHandler(daoyuan);// 设置老师的下一个处理者是导员
        daoyuan.setNextHandler(xiaozhang);// 设置导员的下一个处理者是校长
        String requests = "退学";
        // 把请求交给班长即可，如果班长处理不了会一层层往上交
        banzhang.handleRequest(requests);
    }
}

 

 

总结：
　　责任链模式优点是降低了耦合、提高了灵活性。但是责任链模式可能会带来一些额外的性能损耗，因为它要从链子开头开始遍历。因为无法预知来自外界（客户端）的请求是属于哪种类型，每个类如果碰到它不能处理的请求只要放弃就可以。 
　　缺点是效率低，因为一个请求的完成可能要遍历到最后才可能完成，当然也可以用树的概念优化。 在Java AWT1.0中，对于鼠标按键事情的处理就是使用CoR,到Java.1.1以后，就使用Observer代替CoR；扩展性差，因为在CoR中，一定要有一个统一的接口Handler.局限性就在这里。

适用场合：
•有多个的对象可以处理一个请求，哪个对象处理该请求运行时刻自动确定。
•想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。 
•可处理一个请求的对象集合应被动态指定。
•当一个方法的传入参数将成为分支语句的判断条件，分支条件存在扩展的可能，每一个分支的职责相对独立，且逻辑较为复杂时。