不得不知的责任链设计模式

世界上最遥远的距离，不是生与死，而是它从你的世界路过无数次，你却选择视而不见，你无情，你冷酷啊......

被你忽略的就是责任链设计模式，希望它再次经过你身旁你会猛的发现，并对它微微一笑......

初次见面，了解表象，深入交流之后（看完文中的 demo 和框架中的实际应用后），你我便是灵魂之交（重新站在上帝视角来理解这个概念会更加深刻）

责任链模式（Chain of Responsibility Pattern）为请求创建了一个接收者对象的链。这种模式给予请求的类型，对请求的发送者和接收者进行解耦。这种类型的设计模式属于行为型模式。在这种模式中，通常每个接收者都包含对另一个接收者的引用。如果一个对象能或不能处理该请求，它都会把相同的请求传给下一个接收者，依此类推，直至责任链结束。

接下来将概念图形化，用大脑图形处理区理解此概念

上图左侧的 UML 类图中，Sender 类不直接引用特定的接收器类。 相反，Sender 引用Handler 接口来处理请求handler.handleRequest()，这使得 Sender 独立于具体的接收器（概念当中说的解耦） Receiver1，Receiver2 和 Receiver3 类通过处理或转发请求来实现 Handler 接口（取决于运行时条件）

上图右侧的 UML 序列图显示了运行时交互，在此示例中，Sender 对象在 receiver1 对象（类型为Handler）上调用 handleRequest()， 接收器 1 将请求转发给接收器 2，接收器 2 又将请求转发到处理（执行）请求的接收器3

大家小时候都玩过击鼓传花的游戏，游戏的每个参与者就是责任链中的一个处理对象，花球就是待处理的请求，花球就在责任链（每个参与者中）进行传递，只不过责任链的结束时间点是鼓声的结束. 来看 Demo 和实际案例

程序猿和 log 是老交情了，使用 logback 配置日志的时候有 ConsoleAppender 和 RollingFileAppender，这两个 Appender 就组成了一个 log 记录的责任链。下面的 demo 就是模拟 log 记录：ConsoleLogger 打印所有级别的日志；EmailLogger 记录特定业务级别日志 ；FileLogger 中只记录 warning 和 Error 级别的日志

抽象概念介绍中，说过实现责任链要有一个抽象接收器接口，和具体接收器，demo 中 Logger 就是这个抽象接口，由于该接口是 @FunctionalInterface (函数式接口), 它的具体实现就是 Lambda 表达式，关键代码都已做注释标注

import java.util.Arrays;
import java.util.EnumSet;
import java.util.function.Consumer;

@FunctionalInterface
public interface Logger {
    /**
     * 枚举log等级
     */
    public enum LogLevel {
        //定义 log 等级
        INFO, DEBUG, WARNING, ERROR, FUNCTIONAL_MESSAGE, FUNCTIONAL_ERROR;

        public static LogLevel[] all() {
            return values();
        }
    }

    /**
     * 函数式接口中的唯一抽象方法
     * @param msg
     * @param severity
     */
    abstract void message(String msg, LogLevel severity);

    default Logger appendNext(Logger nextLogger) {
        return (msg, severity) -> {
            // 前序logger处理完才用当前logger处理
            message(msg, severity);
            nextLogger.message(msg, severity);
        };
    }

    static Logger logger(LogLevel[] levels, Consumer writeMessage) {
        EnumSet set = EnumSet.copyOf(Arrays.asList(levels));
        return (msg, severity) -> {
            // 判断当前logger是否能处理传递过来的日志级别
            if (set.contains(severity)) {
                writeMessage.accept(msg);
            }
        };
    }

    static Logger consoleLogger(LogLevel... levels) {
        return logger(levels, msg -> System.err.println("写到终端: " + msg));
    }

    static Logger emailLogger(LogLevel... levels) {
        return logger(levels, msg -> System.err.println("通过邮件发送: " + msg));
    }

    static Logger fileLogger(LogLevel... levels) {
        return logger(levels, msg -> System.err.println("写到日志文件中: " + msg));
    }

    public static void main(String[] args) {
        /**
         * 构建一个固定顺序的链 【终端记录——邮件记录——文件记录】
         * consoleLogger：终端记录，可以打印所有等级的log信息
         * emailLogger：邮件记录，打印功能性问题 FUNCTIONAL_MESSAGE 和 FUNCTIONAL_ERROR 两个等级的信息
         * fileLogger：文件记录，打印 WARNING 和 ERROR 两个等级信息
         */
        
        Logger logger = consoleLogger(LogLevel.all())
                .appendNext(emailLogger(LogLevel.FUNCTIONAL_MESSAGE, LogLevel.FUNCTIONAL_ERROR))
                .appendNext(fileLogger(LogLevel.WARNING, LogLevel.ERROR));

        // consoleLogger 可以记录所有 level 的信息
        logger.message("进入到订单流程，接收到参数，参数内容为XXXX", LogLevel.DEBUG);
        logger.message("订单记录生成.", LogLevel.INFO);

        // consoleLogger 处理完，fileLogger 要继续处理
        logger.message("订单详细地址缺失", LogLevel.WARNING);
        logger.message("订单省市区信息缺失", LogLevel.ERROR);

        // consoleLogger 处理完，emailLogger 继续处理
        logger.message("订单短信通知服务失败", LogLevel.FUNCTIONAL_ERROR);
        logger.message("订单已派送.", LogLevel.FUNCTIONAL_MESSAGE);
    }
}

ConsoleLogger、EmailLogger 和 FileLogger 组成一个责任链，分工明确；FileLogger 中包含 EmailLogger 的引用，EmailLogger 中包含 ConsoleLogger 的引用，当前具体 Logger 是否记录日志的判断条件是传入的 log level 是否在它的责任范围内. 最终调用 message 方法时的责任链顺序 ConsoleLogger -> EmailLogger -> FileLogger. 如果不能很好的理解 Lambda ，我们可以通过接口与实现类的方式实现

为什么说责任链模式从我们身边路过无数次，你却忽视它，看下面这两个案例，你也许会一声长叹.

下面这段代码有没有很熟悉，没错，我们配置拦截器重写 doFilter 方法时都会执行下面这段代码，传递给下一个 Filter 进行处理

chain.doFilter(request, response);

随意定义一个拦截器 CustomFilter，都要执行 chain.doFilter(request, response) 方法进行 Filter 链的传递

import javax.servlet.*;
import java.io.IOException;

/**
 * @author tan日拱一兵
 * @date 2019-06-19 13:45
 */
public class CustomFilter implements Filter {
    @Override
    public void init(FilterConfig filterConfig) throws ServletException {

    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {

    }
}

以 debug 模式启动应用，随意请求一个没有被加入 filter 白名单的接口，都会看到如下的调用栈信息：

红色标记框的内容是 Tomcat 容器设置的责任链，从 Engine 到 Cotext 再到 Wrapper 都是通过这个责任链传递请求，如下类图所示，他们都实现了 Valve 接口中的 invoke 方法

但这并不是这里要说明的重点，这里要看的是和我们自定义 Filter 息息相关的蓝色框的内容 ApplicationFilterChain ，我们要了解它是如何应用责任链设计模式的？

既然是责任链，所有的过滤器是怎样加入到这个链条当中的呢？

ApplicationFilterChain 类中定义了一个 ApplicationFilterConfig 类型的数组，用来保存过滤器

/**
 * Filters.
 */
private ApplicationFilterConfig[] filters = new ApplicationFilterConfig[0];

ApplicationFilterConfig 是什么？

ApplicationFilterConfig 是 Filter 的容器，类的描述是：在 web 第一次启动的时候管理 filter 的实例化

/**
 * Implementation of a javax.servlet.FilterConfig useful in
 * managing the filter instances instantiated when a web application
 * is first started.
 *
 * @author Craig R. McClanahan
 */

ApplicationFilterConfig[] 是一个大小为 0 的空数组，那它在什么时候被重新赋值的呢？

是在 ApplicationFilterChain 类调用 addFilter 的时候重新赋值的

/**
 * The int which gives the current number of filters in the chain.
 */
private int n = 0;

public static final int INCREMENT = 10;

/**
 * Add a filter to the set of filters that will be executed in this chain.
 *
 * @param filterConfig The FilterConfig for the servlet to be executed
 */
void addFilter(ApplicationFilterConfig filterConfig) {

    // Prevent the same filter being added multiple times
    for(ApplicationFilterConfig filter:filters)
        if(filter==filterConfig)
            return;

    if (n == filters.length) {
        ApplicationFilterConfig[] newFilters =
            new ApplicationFilterConfig[n + INCREMENT];
        System.arraycopy(filters, 0, newFilters, 0, n);
        filters = newFilters;
    }
    filters[n++] = filterConfig;

}

变量 n 用来记录当前过滤器链里面拥有的过滤器数目，默认情况下 n 等于 0，ApplicationFilterConfig 对象数组的长度也等于0，所以当第一次调用 addFilter() 方法时，if (n == filters.length) 的条件成立，ApplicationFilterConfig 数组长度被改变。之后 filters[n++] = filterConfig；将变量 filterConfig 放入 ApplicationFilterConfig 数组中并将当前过滤器链里面拥有的过滤器数目+1（注意这里 n++ 的使用）

有了这些我们看整个链是怎样流转起来的
上图红色框的最顶部调用了 StandardWrapperValve 的 invoke 方法：

...
// Create the filter chain for this request
ApplicationFilterChain filterChain =
        ApplicationFilterFactory.createFilterChain(request, wrapper, servlet);
...
filterChain.doFilter(request.getRequest(), response.getResponse());

通过 ApplicationFilterFactory.createFilterChain 实例化 ApplicationFilterChain (工厂模式)，调用 filterChain.doFilter 方法正式进入责任链条，来看该方法，方法内部调用了 internalDoFilter 方法，来看关键代码：

/**
 * The int which is used to maintain the current position
 * in the filter chain.
 */
private int pos = 0;

// Call the next filter if there is one
if (pos < n) {
    ApplicationFilterConfig filterConfig = filters[pos++];
    try {
        Filter filter = filterConfig.getFilter();

        if (request.isAsyncSupported() && "false".equalsIgnoreCase(
                filterConfig.getFilterDef().getAsyncSupported())) {
            request.setAttribute(Globals.ASYNC_SUPPORTED_ATTR, Boolean.FALSE);
        }
        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 {
            filter.doFilter(request, response, this);
        }
    } catch (IOException | ServletException | RuntimeException e) {
        throw e;
    } catch (Throwable e) {
        e = ExceptionUtils.unwrapInvocationTargetException(e);
        ExceptionUtils.handleThrowable(e);
        throw new ServletException(sm.getString("filterChain.filter"), e);
    }
    return;
}

pos 变量用来标记 filter chain 执行的当前位置，然后调用 filter.doFilter(request, response, this); 传递 this （ApplicationFilterChain）进行链路传递，直至 pos > n 的时候停止 (类似击鼓传花中的鼓声停止)，即所有拦截器都执行完毕。

继续向下看另外一个从我们身边路过无数次的责任链模式

Mybatis 拦截器执行过程解析 中留一个问题彩蛋责任链模式，那在 Mybatis 拦截器中是怎样应用的呢？

public class InterceptorChain {

  private final List interceptors = new ArrayList();

  public Object pluginAll(Object target) {
    for (Interceptor interceptor : interceptors) {
      target = interceptor.plugin(target);
    }
    return target;
  }

  public void addInterceptor(Interceptor interceptor) {
    interceptors.add(interceptor);
  }
  
  public List getInterceptors() {
    return Collections.unmodifiableList(interceptors);
  }

}

以 Executor 类型的拦截为例，如果存在多个同类型的拦截器，当执行到 pluginAll 方法时，他们是怎样在责任链条中传递的呢？
调用interceptor.plugin(target) 为当前 target 生成代理对象，当多个拦截器遍历的时候，也就是会继续为代理对象再生成代理对象，直至遍历结束，拿到最外层的代理对象，触发 invoke 方法就可以完成链条拦截器的传递，以图来说明一下

看了这些，你和责任链设计模式会是灵魂之交吗？

敲黑板，敲黑板，敲黑板 （重要的事情敲三次黑板）
看了这么多之后，我们要总结出责任链设计模式的关键了

设计一个链条，和抽象处理方法

将具体处理器初始化到链条中，并做抽象方法具体的实现

具体处理器之间的引用和处理条件判断

设计链条结束标识

1，2 都可以很模块化设计，3，4 设计可以多种多样，比如文中通过 pos 游标，或嵌套动态代理等.

在实际业务中，如果存在相同类型的任务需要顺序执行，我们就可以拆分任务，将任务处理单元最小化，这样易复用，然后串成一个链条，应用责任链设计模式就好了. 同时读框架源码时如果看到 chain 关键字，也八九不离十是应用责任链设计模式了，看看框架是怎样应用责任链设计模式的。

现在请你回看文章开头，重新站在上帝视角审视责任链设计模式，什么感觉，欢迎留言交流

Lambda 函数式编程，你可以灵活应用，实现优雅编程吗？

多个拦截器或过滤器，如果需要特定的责任链顺序，我们都有哪些方式控制顺序？

](https://upload-images.jianshu...

留言中有朋友让我推荐一款 MarkDown 编辑器，我用过很多种（包括在线的），这次推荐 VNote, VNote 是一个受Vim启发的更懂程序员和Markdown的一个笔记软件, 都说 vim是最好的编辑器，更懂程序猿，但是多数还是应用在类 Unix 环境的 shell 脚本编写中，熟练使用 vim 也是我们必备的基本功，VNote 满足这一切需求，同时提供非常多方便的快捷键满足日常 MarkDown 的编写. 通过写文字顺路学习 vim，快哉...