设计模式 | 责任链模式及典型应用

本文的主要内容：

• 介绍责任链模式
• 请假流程示例
• 责任链模式总结
• 源码分析Tomcat Filter中的责任链模式

更多内容可访问我的个人博客：laijianfeng.org
关注【小旋锋】微信公众号，及时接收博文推送

****

---

责任链模式

一个事件需要经过多个对象处理是一个挺常见的场景，譬如采购审批流程，请假流程，软件开发中的异常处理流程，web请求处理流程等各种各样的流程，可以考虑使用责任链模式来实现。

以请假流程为例，一般公司普通员工的请假流程简化如下：

普通员工发起一个请假申请，当请假天数小于3天时只需要得到主管批准即可；当请假天数大于3天时，主管批准后还需要提交给经理审批，经理审批通过，若请假天数大于7天还需要进一步提交给总经理审批。

使用 if-else 来实现这个请假流程的简化代码如下：

public class LeaveApproval {
    public boolean process(String request, int number) {
        boolean result = handleByDirector(request); // 主管处理
        if (result == false) {  // 主管不批准
            return false;
        } else if (number < 3) {    // 主管批准且天数小于 3
            return true;
        }

        result = handleByManager(request); // 准管批准且天数大于等于 3，提交给经理处理
        if (result == false) {   // 经理不批准
            return false;
        } else if (number < 7) { // 经理批准且天数小于 7
            return true;
        }

        result = handleByTopManager(request);   // 经理批准且天数大于等于 7，提交给总经理处理
        if (result == false) { // 总经理不批准
            return false;
        }
        return true;    // 总经理最后批准
    }

    public boolean handleByDirector(String request) {
        // 主管处理该请假申请
    }

    public boolean handleByManager(String request) {
        // 经理处理该请假申请
    }

    public boolean handleByTopManager(String request) {
        // 总经理处理该请假申请
    }
}
复制代码

问题看起来很简单，三下五除二就搞定，但是该方案存在几个问题：

1. LeaveApproval 类比较庞大，各个上级的审批方法都集中在该类中，违反了 "单一职责原则"，测试和维护难度大

2. 当需要修改该请假流程，譬如增加当天数大于30天时还需提交给董事长处理，必须修改该类源代码（并重新进行严格地测试），违反了 "开闭原则"

3. 该流程缺乏灵活性，流程确定后不可再修改（除非修改源代码），客户端无法定制流程

使用责任链模式可以解决上述问题。

定义

责任链模式(Chain of Responsibility Pattern)：避免请求发送者与接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止。职责链模式是一种对象行为型模式。

角色

Handler（抽象处理者）：它定义了一个处理请求的接口，一般设计为抽象类，由于不同的具体处理者处理请求的方式不同，因此在其中定义了抽象请求处理方法。因为每一个处理者的下家还是一个处理者，因此在抽象处理者中定义了一个抽象处理者类型的对象，作为其对下家的引用。通过该引用，处理者可以连成一条链。

ConcreteHandler（具体处理者）：它是抽象处理者的子类，可以处理用户请求，在具体处理者类中实现了抽象处理者中定义的抽象请求处理方法，在处理请求之前需要进行判断，看是否有相应的处理权限，如果可以处理请求就处理它，否则将请求转发给后继者；在具体处理者中可以访问链中下一个对象，以便请求的转发。

类图如下所示：

纯与不纯的责任链模式

纯的责任链模式：

• 一个具体处理者对象只能在两个行为中选择一个：要么承担全部责任，要么将责任推给下家，不允许出现某一个具体处理者对象在承担了一部分或全部责任后 又将责任向下传递的情况
• 一个请求必须被某一个处理者对象所接收，不能出现某个请求未被任何一个处理者对象处理的情况

不纯的责任链模式：

• 允许某个请求被一个具体处理者部分处理后再向下传递
• 或者一个具体处理者处理完某请求后其后继处理者可以继续处理该请求
• 而且一个请求可以最终不被任何处理者对象所接收

示例

使用责任链模式（不纯）重构请假流程

请假信息类，包含请假人姓名和请假天数

@Data
@AllArgsConstructor
public class LeaveRequest {
    private String name;    // 请假人姓名
    private int numOfDays;  // 请假天数
}
复制代码

抽象处理者类 Handler，维护一个 nextHandler 属性，该属性为当前处理者的下一个处理者的引用；声明了抽象方法 process

@Data
public abstract class Handler {
    protected String name; // 处理者姓名
    protected Handler nextHandler;  // 下一个处理者

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

    public abstract boolean process(LeaveRequest leaveRequest); // 处理请假
}
复制代码

三个具体处理类，分别实现了抽象处理类的 process 方法

// 主管处理者
public class Director extends Handler {
    public Director(String name) {
        super(name);
    }

    @Override
    public boolean process(LeaveRequest leaveRequest) {
        boolean result = (new Random().nextInt(10)) > 3; // 随机数大于3则为批准，否则不批准
        String log = "主管<%s> 审批 <%s> 的请假申请，请假天数： <%d> ，审批结果：<%s> ";
        System.out.println(String.format(log, this.name, leaveRequest.getName(), leaveRequest.getNumOfDays(), result == true ? "批准" : "不批准"));

        if (result == false) {  // 不批准
            return false;
        } else if (leaveRequest.getNumOfDays() < 3) { // 批准且天数小于3，返回true
            return true;
        }
        return nextHandler.process(leaveRequest);   // 批准且天数大于等于3，提交给下一个处理者处理
    }
}

// 经理
public class Manager extends Handler {
    public Manager(String name) {
        super(name);
    }

    @Override
    public boolean process(LeaveRequest leaveRequest) {
        boolean result = (new Random().nextInt(10)) > 3; // 随机数大于3则为批准，否则不批准
        String log = "经理<%s> 审批 <%s> 的请假申请，请假天数： <%d> ，审批结果：<%s> ";
        System.out.println(String.format(log, this.name, leaveRequest.getName(), leaveRequest.getNumOfDays(), result == true ? "批准" : "不批准"));

        if (result == false) {  // 不批准
            return false;
        } else if (leaveRequest.getNumOfDays() < 7) { // 批准且天数小于7
            return true;
        }
        return nextHandler.process(leaveRequest);   // 批准且天数大于等于7，提交给下一个处理者处理
    }
}

// 总经理
public class TopManager extends Handler {
    public TopManager(String name) {
        super(name);
    }

    @Override
    public boolean process(LeaveRequest leaveRequest) {
        boolean result = (new Random().nextInt(10)) > 3; // 随机数大于3则为批准，否则不批准
        String log = "总经理<%s> 审批 <%s> 的请假申请，请假天数： <%d> ，审批结果：<%s> ";
        System.out.println(String.format(log, this.name, leaveRequest.getName(), leaveRequest.getNumOfDays(), result == true ? "批准" : "不批准"));

        if (result == false) { // 总经理不批准
            return false;
        }
        return true;    // 总经理最后批准
    }
}
复制代码

客户端测试

public class Client {
    public static void main(String[] args) {
        Handler zhangsan = new Director("张三");
        Handler lisi = new Manager("李四");
        Handler wangwu = new TopManager("王五");

        // 创建责任链
        zhangsan.setNextHandler(lisi);
        lisi.setNextHandler(wangwu);

        // 发起请假申请
        boolean result1 = zhangsan.process(new LeaveRequest("小旋锋", 1));
        System.out.println("最终结果：" + result1 + "\n");

        boolean result2 = zhangsan.process(new LeaveRequest("小旋锋", 4));
        System.out.println("最终结果：" + result2 + "\n");

        boolean result3 = zhangsan.process(new LeaveRequest("小旋锋", 8));
        System.out.println("最终结果：" + result3 + "\n");
    }
}
复制代码

可能的结果如下：（由于是否批准是通过随机数模拟的，所以你的结果可能跟我不同）

主管<张三> 审批 <小旋锋> 的请假申请，请假天数： <1> ，审批结果：<批准> 
最终结果：true

主管<张三> 审批 <小旋锋> 的请假申请，请假天数： <4> ，审批结果：<不批准> 
最终结果：false

主管<张三> 审批 <小旋锋> 的请假申请，请假天数： <8> ，审批结果：<批准> 
经理<李四> 审批 <小旋锋> 的请假申请，请假天数： <8> ，审批结果：<批准> 
总经理<王五> 审批 <小旋锋> 的请假申请，请假天数： <8> ，审批结果：<批准> 
最终结果：true
复制代码

类图如下所示

总结

职责链模式的主要优点

• 对象仅需知道该请求会被处理即可，且链中的对象不需要知道链的结构，由客户端负责链的创建，降低了系统的耦合度

• 请求处理对象仅需维持一个指向其后继者的引用，而不需要维持它对所有的候选处理者的引用，可简化对象的相互连接

• 在给对象分派职责时，职责链可以给我们更多的灵活性，可以在运行时对该链进行动态的增删改，改变处理一个请求的职责

• 新增一个新的具体请求处理者时无须修改原有代码，只需要在客户端重新建链即可，符合 "开闭原则"

职责链模式的主要缺点

• 一个请求可能因职责链没有被正确配置而得不到处理

• 对于比较长的职责链，请求的处理可能涉及到多个处理对象，系统性能将受到一定影响，且不方便调试

• 可能因为职责链创建不当，造成循环调用，导致系统陷入死循环

适用场景

• 有多个对象可以处理同一个请求，具体哪个对象处理该请求待运行时刻再确定，客户端只需将请求提交到链上，而无须关心请求的处理对象是谁以及它是如何处理的

• 在不明确指定接收者的情况下，向多个对象中的一个提交一个请求

• 可动态指定一组对象处理请求，客户端可以动态创建职责链来处理请求，还可以改变链中处理者之间的先后次序

责任链模式的典型应用

Tomcat 过滤器中的责任链模式

Servlet 过滤器是可用于 Servlet 编程的 Java 类，可以实现以下目的：在客户端的请求访问后端资源之前，拦截这些请求；在服务器的响应发送回客户端之前，处理这些响应。

Servlet 定义了过滤器接口 Filter 和过滤器链接口 FilterChain 的源码如下

public interface Filter {
    public void init(FilterConfig filterConfig) throws ServletException;
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException;
    public void destroy();
}

public interface FilterChain {
    void doFilter(ServletRequest var1, ServletResponse var2) throws IOException, ServletException;
}
复制代码

我们自定义一个过滤器的步骤是：

1）写一个过滤器类，实现 javax.servlet.Filter 接口，如下所示

public class MyFilter implements Filter {
    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException {
        // 做一些自定义处理....
        System.out.println("执行doFilter()方法之前...");
        chain.doFilter(request, response);              // 传递请求给下一个过滤器
        System.out.println("执行doFilter()方法之后...");
    }

    @Override
    public void destroy() {
    }

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
    }
}
复制代码

2）在 web.xml 文件中增加该过滤器的配置，譬如下面是拦截所有请求

<filter>  
        <filter-name>MyFilter</filter-name>  
        <filter-class>com.whirly.filter.MyFilter</filter-class>  
</filter>
  
<filter-mapping>  
        <filter-name>MyFilter</filter-name>  
        <url-pattern>/*</url-pattern>  
</filter-mapping>
复制代码

当启动 Tomcat 是我们的过滤器就可以发挥作用了。那么过滤器是怎样运行的呢？

Tomcat 有 Pipeline Valve机制，也是使用了责任链模式，一个请求会在 Pipeline 中流转，Pipeline 会调用相应的 Valve 完成具体的逻辑处理；
其中的一个基础Valve为 StandardWrapperValve，其中的一个作用是调用 ApplicationFilterFactory 生成 Filter链，具体代码在 invoke 方法中

在运行过滤器之前需要完成过滤器的加载和初始化，以及根据配置信息生成过滤器链：

1. 过滤器的加载具体是在 ContextConfig 类的 configureContext 方法中，分别加载 filter 和 filterMap 的相关信息，并保存在上下文环境中

2. 过滤器的初始化在 StandardContext 类的 startInternal 方法中完成，保存在 filterConfigs 中并存到上下文环境中

3. 请求流转到 StandardWrapperValve 时，在 invoke 方法中，会根据过滤器映射配置信息，为每个请求创建对应的 ApplicationFilterChain，其中包含了目标 Servlet 以及对应的过滤器链，并调用过滤器链的 doFilter 方法执行过滤器

StandardWrapperValve 调用 ApplicationFilterFactory 为请求创建过滤器链并调用过滤器链的关键代码如下:

final class StandardWrapperValve extends ValveBase {
    public final void invoke(Request request, Response response) throws IOException, ServletException {
        // 省略其他的逻辑处理...
        // 调用 ApplicationFilterChain.createFilterChain() 创建过滤器链
        ApplicationFilterChain filterChain = ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);
        
        if (servlet != null && filterChain != null) {
            // 省略
        } else if (request.isAsyncDispatching()) {
            request.getAsyncContextInternal().doInternalDispatch();
        } else if (comet) {
            filterChain.doFilterEvent(request.getEvent());
        } else {
            // 调用过滤器链的 doFilter 方法开始过滤
            filterChain.doFilter(request.getRequest(), response.getResponse());
        }
复制代码

过滤器链 ApplicationFilterChain 的关键代码如下，过滤器链实际是一个 ApplicationFilterConfig 数组

final class ApplicationFilterChain implements FilterChain, CometFilterChain {
    private ApplicationFilterConfig[] filters = new ApplicationFilterConfig[0]; // 过滤器链
    private Servlet servlet = null; // 目标
    // ...
    
    @Override
    public void doFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException {
        if( Globals.IS_SECURITY_ENABLED ) {
            // ...
        } else {
            internalDoFilter(request,response); // 调用 internalDoFilter 方法
        }
    }
    
    private void internalDoFilter(ServletRequest request, ServletResponse response) throws IOException, ServletException {
        // Call the next filter if there is one
        if (pos < n) {
            // 从过滤器数组中取出当前过滤器配置，然后下标自增1
            ApplicationFilterConfig filterConfig = filters[pos++];
            Filter filter = null;
            try {
                filter = filterConfig.getFilter();  // 从过滤器配置中取出该 过滤器对象

                if( Globals.IS_SECURITY_ENABLED ) {
                    final ServletRequest req = request;
                    final ServletResponse res = response;
                    Principal principal = ((HttpServletRequest) req).getUserPrincipal();

                    Object[] args = new Object[]{req, res, this};
                    SecurityUtil.doAsPrivilege("doFilter", filter, classType, args, principal);
                } else {
                    // 调用过滤器的 doFilter，完成一个过滤器的过滤功能
                    filter.doFilter(request, response, this);
                }
            return;  // 这里很重要，不会重复执行后面的  servlet.service(request, response)
        }
        
        // 执行完过滤器链的所有过滤器之后，调用 Servlet 的 service 完成请求的处理
        if ((request instanceof HttpServletRequest) && (response instanceof HttpServletResponse)) {
            if( Globals.IS_SECURITY_ENABLED ) {
                
            } else {
                servlet.service(request, response);
            }
        } else {
            servlet.service(request, response);
        }
    }
    // 省略...
}
复制代码

过滤器

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        System.out.println("执行doFilter()方法之前...");
        chain.doFilter(request, response);              // 传递请求给下一个过滤器
        System.out.println("执行doFilter()方法之后...");
    }
复制代码

当下标小于过滤器数组长度 n 时，说明过滤器链未执行完，所以从数组中取出当前过滤器，调用过滤器的 doFilter 方法完成过滤处理，在过滤器的 doFilter 中又调用 FilterChain 的 doFilter，回到 ApplicationFilterChain，又继续根据下标是否小于数组长度来判断过滤器链是否已执行完，未完则继续从数组取出过滤器并调用 doFilter 方法，所以这里的过滤链是通过嵌套递归的方式来串成一条链。

当全部过滤器都执行完毕，最后一次进入 ApplicationFilterChain.doFilter 方法的时候 pos < n 为false，不进入 if (pos < n) 中，而是执行后面的代码，判断 (request instanceof HttpServletRequest) && (response instanceof HttpServletResponse)，若为 http 请求则调用 servlet.service(request, response); 来处理该请求。

处理完毕之后沿着调用过滤器的顺序反向退栈，分别执行过滤器中 chain.doFilter() 之后的处理逻辑，需要注意的是在 if (pos < n) 方法体的最后有一个 return;，这样就保证了只有最后一次进入 ApplicationFilterChain.doFilter 方法的调用能够执行后面的 servlet.service(request, response) 方法

画一个简要的调用栈如下所示：

ApplicationFilterChain 类扮演了抽象处理者角色，具体处理者角色由各个 Filter 扮演

其他的责任链模式的典型应用

其他的责任链模式的应用基本都是大同小异

这里列举几个典型应用：

1. Netty 中的 Pipeline 和 ChannelHandler 通过责任链设计模式来组织代码逻辑
2. Spring Security 使用责任链模式，可以动态地添加或删除责任（处理 request 请求）
3. Spring AOP 通过责任链模式来管理 Advisor
4. Dubbo Filter 过滤器链也是用了责任链模式（链表），可以对方法调用做一些过滤处理，譬如超时(TimeoutFilter)，异常(ExceptionFilter)，Token(TokenFilter)等
5. Mybatis 中的 Plugin 机制使用了责任链模式，配置各种官方或者自定义的 Plugin，与 Filter 类似，可以在执行 Sql 语句的时候做一些操作

---

参考：
刘伟：设计模式Java版
慕课网java设计模式精讲 Debug 方式+内存分析
责任链设计模式（过滤器、拦截器）

后记

欢迎评论、转发、分享，您的支持是我最大的动力

推荐阅读

设计模式 | 简单工厂模式及典型应用
设计模式 | 工厂方法模式及典型应用
设计模式 | 抽象工厂模式及典型应用
设计模式 | 建造者模式及典型应用
设计模式 | 原型模式及典型应用
设计模式 | 外观模式及典型应用
设计模式 | 装饰者模式及典型应用
设计模式 | 适配器模式及典型应用
设计模式 | 享元模式及典型应用
设计模式 | 组合模式及典型应用
设计模式 | 模板方法模式及典型应用
设计模式 | 迭代器模式及典型应用
设计模式 | 策略模式及典型应用
设计模式 | 观察者模式及典型应用
设计模式 | 备忘录模式及典型应用
设计模式 | 中介者模式及典型应用