Java设计模式之——责任链模式

责任链模式简单介绍

责任链模式，是行为性设计模式之一。什么是“链”？我们将多个节点首尾相连构成的模型称为链，比如生活中常见的锁链，就是由一个个圆角长方形的铁环串起来的结构。对于链式结构，每个节点都可以被拆开在连接，因此，链式结构也具有很好的灵活性。将这样一种结构应用于编程领域，将每一个节点看作是一个对象，每一个对象拥有不同的处理逻辑，将一个请求从链式的首端发出，沿着链的路径依次传递给每一个节点对象，直至有对象处理这个请求为止，我们将这样的一种模式称为责任链模式，这样的解释是不是更通俗易懂呢？我们还是看看责任链模式的标准定义。

责任链模式的定义

使多个对象都有机会处理请求，从而避免了请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有对象处理它为止。

责任链模式的使用场景

• 多个对象可以处理同一请求，但具体由哪个对象处理则在运行时动态决定；
• 在请求处理着不明确的情况下向多个对象的一个提交一个请求；
• 需要动态指定一组对象处理请求。

责任链模式的 UML 类图

是不是感觉看上去和前面咱们介绍的策略模式以及状态模式大同小异，是，大概类图表现形式上是一样的，但是其实现细节有很大区别，具体实现我们等会再说，先来看看具体的角色说明：

角色说明：

• Handler：抽象处理者角色，声明一个请求处理方法，并在其中保持一个对下一个处理节点 Handler 对象的引用。
• ConcreteHandler：具体处理者角色，对请求进行处理，如果不能处理则将该请求转发给下一个节点上的处理对象。

根据类图可以得出一个责任链模式简化版的通用模式代码：注意是简化版噢，后面会有很复杂的东东在等着我们。

public abstract class Handler {
    protected Handler nextHandler;    //下一节点的处理者

    /**
     * 请求处理
     *
     * @param condition 请求条件
     */
    public abstract void handleRequest(String condition);
}

/**
 * 具体的处理者1
 */
public class ConcreteHandler1 extends Handler {
    @Override
    public void handleRequest(String condition) {
        if (condition.equals("ConcreteHandler1")) {
            Log.d("Handler", "ConcreteHandler1 handled");
            return;
        } else {
            nextHandler.handleRequest(condition);
        }
    }
}

/**
 * 具体的处理者2
 */
public class ConcreteHandler2 extends Handler {
    @Override
    public void handleRequest(String condition) {
        if (condition.equals("ConcreteHandler2")) {
            Log.d("Handler", "ConcreteHandler2 handled");
            return;
        } else {
            nextHandler.handleRequest(condition);
        }
    }
}

/**
 * 客户类
 */
public class Client {
    public static void main() {
        //构造一个 ConcreteHandler1 对象
        ConcreteHandler1 handler1 = new ConcreteHandler1();

        //构造一个 ConcreteHandler2 对象
        ConcreteHandler2 handler2 = new ConcreteHandler2();

        //设置 handler1 的下一个节点
        handler1.nextHandler= handler2;

        //设置 handler2 的下一个节点
        handler2.nextHandler= handler1;

        //处理请求
        handler1.handleRequest("ConcreteHandler1");
    }
}

上面我们说到这是一个简化版的通用模式代码，为什么这么说呢？因为对于请求来说，其形式是固定的，就是一个字符串，而判断一个节点上的对象是否能够处理该请求的标志，则是该字符串是否与之匹配。然而在大多数情况下，责任链的请求和对应的处理规则是不尽相同的，在这种情况下可以将请求进行封装，同时对请求的处理规则也进行封装作为一个独立的对象，类图如下所示：

其实也没有复杂多少，无外乎就是增加了一个 抽象请求者，已经相应的 具体实现类。

我们这里也给出相应的模板代码：

首先我们先来看 AbstractHandler 抽象处理者，其声明了处理者对象处理请求的方法和获取处理者级别的方法，并对具体的处理转发逻辑进行了实现。

/**
 * 抽象处理者
 */
public abstract class AbstractHandler {
    protected AbstractHandler nextHandler;

    public final void handleRequest(AbstractRequest request) {
        //判断当前处理者对象的处理级别是否与请求者的处理级别一致
        if (getHandleLevel() == request.getRequestLevel()) {
            //一致则交由该处理对象处理
            handler(request);
        } else {
            //否则将该请求对象转发给下一个节点上的请求对象
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                Log.d("AbstractHandler", "All of handler can not handler the request");
            }
        }
    }

    /**
     * 获取处理者对象的处理级别
     *
     * @return 处理级别
     */
    public abstract int getHandleLevel();

    /**
     * 每个处理者对象的具体处理方式
     *
     * @param request 请求者对象
     */
    protected abstract void handler(AbstractRequest request);
}

在这种情况下我们的责任转发逻辑由抽象处理类控制，而对于抽象请求者，其内部也声明了一个获取请求级别的方法，其与抽象抽象处理者中返回的处理级别保持对应，什么级别的处理逻辑就对应什么样的请求级别。

/**
 * 抽象请求者
 */
public abstract class AbstractRequest {
    private Object obj;     //处理对象

    public AbstractRequest(Object obj) {
        this.obj = obj;
    }

    /**
     * 获取处理的内容对象
     *
     * @return 具体的内容对象
     */
    public Object getContent() {
        return obj;
    }

    /**
     * 获取请求级别
     *
     * @return 请求级别
     */
    public abstract int getRequestLevel();
}

/**
 * 具体请求者 ConcreteRequest1
 */
public class ConcreteRequest1 extends AbstractRequest {
    public ConcreteRequest1(Object obj) {
        super(obj);
    }

    @Override
    public int getRequestLevel() {
        return 1;
    }
}

/**
 * 具体请求者 ConcreteRequest2
 */
public class ConcreteRequest2 extends AbstractRequest {
    public ConcreteRequest2(Object obj) {
        super(obj);
    }

    @Override
    public int getRequestLevel() {
        return 2;
    }
}

/**
 * 具体请求者 ConcreteRequest3
 */
public class ConcreteRequest3 extends AbstractRequest {
    public ConcreteRequest3(Object obj) {
        super(obj);
    }

    @Override
    public int getRequestLevel() {
        return 3;
    }
}



/**
 * 具体处理者 ConcreteHandler1
 */
public class ConcreteHandler1 extends AbstractHandler {
    @Override
    public int getHandleLevel() {
        return 1;
    }

    @Override
    protected void handler(AbstractRequest request) {
        Log.d("AbstractHandler", "ConcreteHandler1 handler request:" + request.getRequestLevel());
    }
}

/**
 * 具体处理者 ConcreteHandler2
 */
public class ConcreteHandler2 extends AbstractHandler {
    @Override
    public int getHandleLevel() {
        return 1;
    }

    @Override
    protected void handler(AbstractRequest request) {
        Log.d("AbstractHandler", "ConcreteHandler2 handler request:" + request.getRequestLevel());
    }
}

/**
 * 具体处理者 ConcreteHandler3
 */
public class ConcreteHandler3 extends AbstractHandler {
    @Override
    public int getHandleLevel() {
        return 1;
    }

    @Override
    protected void handler(AbstractRequest request) {
        Log.d("AbstractHandler", "ConcreteHandler3 handler request:" + request.getRequestLevel());
    }
}


/**
 * 客户端
 */
public class Client {
    public static void main() {
        //构造 3 个处理者
        AbstractHandler handler1 = new ConcreteHandler1();
        AbstractHandler handler2 = new ConcreteHandler2();
        AbstractHandler handler3 = new ConcreteHandler3();

        //设置当前处理者对象下一个节点的处理者对象
        handler1.nextHandler = handler2;
        handler2.nextHandler = handler3;

        //构造 3 个请求者对象
        AbstractRequest request1 = new ConcreteRequest1("Request1");
        AbstractRequest request2 = new ConcreteRequest2("Request2");
        AbstractRequest request3 = new ConcreteRequest3("Request3");

        //总是从链式的首端发起请求
        handler1.handleRequest(request1);
        handler2.handleRequest(request2);
        handler3.handleRequest(request3);
    }
}

责任链模式实战

讲一个实际生活中的例子，比如说某天你接到通知说需要出差去X国进修学习新技术，然后你就收拾一下背包就踏上了旅途。而回来一算这趟X国学习一共花费了近 5万元，于是你就拿着票据去找组长申请报销费用，组长一看是笔不小的数目，他没有权限审批，于是组长就拿着票据去找了部门组管，组管一看要报这么多钱，自己权限内只能批五千一下的费用，这完全超出了自己的权限范围，于是组管又跑去找经理，经理一看二话不说直接拿着票据奔向了老板的办公室，因为他也只能批一万以下的费用。类似额情况对于上班族来说肯定不少见，上面的这个情景其实就是一个责任链的小例子，每一个人，准确地说是每一类人代表这条链上的一个节点，你是请求的发起者，而老板则是处于链条顶端的类，你从链的低端开始发出一个申请报账的请求，首先有组长处理该请求，组长对比后发现自己权限不够于是将该请求转发给位于链中下一个节点的组管，组管对比后也发现自己的权限不够又将该请求转发给经理，而经理也基于同样的原因将请求转发给老板，这样层层转达直至请求被处理，从中大家可以看见一个显而易见的事，就是至始至终你只与组长产生了关联，后面具体由谁负责处理票据，你并不关心，唯一在乎的是报账的结果，责任链模式在这里很好地将请求的发起者与处理者解耦。如果我们在代码中模拟这个过程也是很直观的，首先还是先生命一个抽象的领导类。

/**
 * 抽象领导者
 */
public abstract class Leader {
    protected Leader nextLeader;

    /**
     * 处理报账请求
     * @param money 申请的报账额度
     */
    public final void handlerRequest(int money) {
        if (money <= limit()){
            handler(money);
        }else{
            if (null != nextLeader){
                nextLeader.handlerRequest(money);
            }
        }
    }

    /**
     * 自身能批复的额度权限
     * @return 额度
     */
    public abstract int limit();

    /**
     * 处理报账行为
     * @param money 申请的报账额度
     */
    public abstract void handler(int money);
}

在这个抽象的领导类中只做了两件事，一是定义了两个抽象接口方法来确定一个领导者应有的行为和属性；二是声明了一个处理报账请求的方法来确定当前领导是否有能力来处理报账请求，如果没有权限，则将该请求转发给上级领导处理。接下来则是各个领导类的实现。

public class GroupLeader extends Leader {
    @Override
    public int limit() {
        return 1000;
    }

    @Override
    public void handler(int money) {
        Log.d("Leader", "组长批复报销" + money + "元");
    }
}

public class DirectorLeader extends Leader {
    @Override
    public int limit() {
        return 5000;
    }

    @Override
    public void handler(int money) {
        Log.d("Leader", "主管批复报销" + money + "元");
    }
}

public class Manager extends Leader {
    @Override
    public int limit() {
        return 10000;
    }

    @Override
    public void handler(int money) {
        Log.d("Leader", "经理批复报销" + money + "元");
    }
}

public class Boos extends Leader {
    @Override
    public int limit() {
        return Integer.MAX_VALUE;
    }

    @Override
    public void handler(int money) {
        Log.d("Leader", "老板批复报销" + money + "元");
    }
}

最后，你从组长开始发起请求申请报账：

public class Test {
    public static void main() {
        //构造各个领导对象
        Leader group = new GroupLeader();
        Leader director = new DirectorLeader();
        Leader manager = new Manager();
        Leader boos = new Boos();

        //设置上一级领导处理者对象
        group.nextLeader = director;
        director.nextLeader = manager;
        manager.nextLeader = boos;

        group.handlerRequest(50000);
    }
}

这里大家可能会想，可不可以直接越过组长找主管报账呢？答案是肯定的，这也是责任链模式的灵活之处，请求的发起可以从责任链的任何一个节点处开始，同时也可以改变责任链内部传递的规则，如主管不在，我们完全可以跨过主管从组长直接将请求转送给经理。

对于责任链中的一个处理者对象，其只有两个行为：一是处理请求；二是将请求转送给下一个节点，不允许某个请求处理者对象在处理了请求后又将请求转送给上一个节点的情况。对于一条责任链来说，一个请求最总只有两种情况，一是被某个处理对象所处理，另一个是所有对象均为对其处理，对于前一种情况我们称该责任链为纯的责任链，对于后一种情况我们称为不纯的责任链，在实际应用中，我们所见到的责任链模式大多为不纯的责任链。

其实责任链模式的应用在 Android 中很普遍，比如我们前面博客中提到的 事件分发 以及 我们常用的 广播接受者 等等都是使用的责任链模式。事件分发机制：每当用户接触屏幕时，Android 都会将对应的事件包装成一个事件对象从 ViewTree 的顶部至上而下地分发传递。

总结

世界不是完美的，所以不会有完美的事物存在。就像所有的设计模式一样，有优点也有缺点，但总体来说优点必定大于缺点或者说缺点相对于优点来说更可控。责任链模式也是一样，优点显而易见，可以对请求者和处理者关系解耦，提高代码的灵活性。责任链模式的最大缺点是对链中请求处理者的遍历，如果处理者太多那么遍历必定会影响性能，特别是在一些递归调用中，要慎重。