设计模式(行为型)-责任链模式

定义

        责任链模式的核心定义是：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。这一模式的本质是建立一个灵活的处理流程，让请求在不同的处理器之间流转，每个处理器根据自身职责决定是否处理请求，或者将其传递给下一个处理器。​

        从本质上来说，责任链模式模拟了现实生活中的 “逐级上报” 或 “分工协作” 机制。比如在公司中，一个员工遇到问题时，会先向自己的直属上司汇报，如果上司能解决就直接处理，如果不能解决就向上级领导汇报，以此类推，直到问题被解决或者到达最高管理层。这种机制既保证了问题能够被合适的人处理，又避免了员工直接与各级领导产生复杂的联系，责任链模式正是对这种机制的抽象和模拟。

类图

角色

        要理解责任链模式，首先需要明确其包含的三大核心角色，它们相互配合，共同构成了模式的运行框架。

Client（客户端）​

        客户端是请求的发起者，它的主要职责是实例化一个处理器的链，并在第一个链对象中调用handleRequest方法，启动请求的处理流程。客户端无需知道链中具体有哪些处理器，也无需关心请求最终由哪个处理器处理，只需将请求传递给链的起点即可。​

        例如，在一个电商平台的订单处理系统中，客户端可能是用户提交订单的操作，用户只需要点击提交按钮，订单请求就会进入处理链，而用户不需要知道订单会经过库存检查、支付验证、物流安排等哪些具体的处理环节。​

Handle（处理器）​

        处理器是一个抽象类，它为所有具体处理器提供了统一的接口。该抽象类中通常会定义一个指向链中下一个处理器的引用，以及一个抽象的handleRequest方法。这个抽象方法是处理请求的核心，由具体处理器来实现。​

        处理器抽象类的存在，保证了所有具体处理器在接口上的一致性，使得客户端可以以统一的方式与处理器进行交互，同时也为处理器之间的链接提供了基础。通过定义下一个处理器的引用，使得每个处理器都知道自己的 “接班人”，从而形成一条完整的处理链。​

ConcreteHandler（具体处理器）​

        具体处理器是继承自Handle的类，它们实现了handleRequest方法，负责处理具体的业务逻辑。不同的业务模块会有不同的ConcreteHandler，每个具体处理器在接收到请求后，会判断自己是否有能力处理该请求。如果可以处理，则直接进行处理；如果不能处理，则将请求传递给链中的下一个处理器。​

        比如在上述电商平台的订单处理系统中，库存检查处理器、支付验证处理器、物流安排处理器等都是具体处理器。库存检查处理器会判断库存是否充足，如果充足就将请求传递给支付验证处理器；支付验证处理器会验证用户的支付信息是否有效，有效则传递给物流安排处理器；物流安排处理器则会安排商品的发货事宜。

实现原理

        责任链模式的实现关键在于处理器之间的链接和请求的传递机制。下面通过一个简单的代码示例来详细说明责任链模式的实现原理。

        首先，定义处理器抽象类：

public abstract class Handler {
    protected Handler nextHandler;

    public void setNextHandler(Handler nextHandler) {
        this.nextHandler = nextHandler;
    }

    public abstract void handleRequest(Request request);
}

        在这个抽象类中，nextHandler用于指向链中的下一个处理器，setNextHandler方法用于设置下一个处理器，handleRequest是抽象方法，由具体处理器实现。​

        然后，定义具体处理器。假设我们有三个具体处理器：ConcreteHandlerA、ConcreteHandlerB、ConcreteHandlerC，分别处理不同范围的请求：

public class ConcreteHandlerA extends Handler {
    @Override
    public void handleRequest(Request request) {
        if (request.getLevel() <= 10) {
            System.out.println("ConcreteHandlerA 处理请求：" + request.getContent());
        } else {
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                System.out.println("没有处理器能处理该请求");
            }
        }
    }
}

public class ConcreteHandlerB extends Handler {
    @Override
    public void handleRequest(Request request) {
        if (request.getLevel() > 10 && request.getLevel() <= 20) {
            System.out.println("ConcreteHandlerB 处理请求：" + request.getContent());
        } else {
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                System.out.println("没有处理器能处理该请求");
            }
        }
    }
}

public class ConcreteHandlerC extends Handler {
    @Override
    public void handleRequest(Request request) {
        if (request.getLevel() > 20 && request.getLevel() <= 30) {
            System.out.println("ConcreteHandlerC 处理请求：" + request.getContent());
        } else {
            if (nextHandler != null) {
                nextHandler.handleRequest(request);
            } else {
                System.out.println("没有处理器能处理该请求");
            }
        }
    }
}

        这里的Request类是请求的封装，包含请求的级别和内容：

public class Request {
    private int level;
    private String content;

    public Request(int level, String content) {
        this.level = level;
        this.content = content;
    }

    public int getLevel() {
        return level;
    }

    public String getContent() {
        return content;
    }
}

        最后，客户端代码如下：

public class Client {
    public static void main(String[] args) {
        // 创建具体处理器
        Handler handlerA = new ConcreteHandlerA();
        Handler handlerB = new ConcreteHandlerB();
        Handler handlerC = new ConcreteHandlerC();

        // 设置处理器链
        handlerA.setNextHandler(handlerB);
        handlerB.setNextHandler(handlerC);

        // 创建请求并处理
        Request request1 = new Request(5, "请求1");
        handlerA.handleRequest(request1);

        Request request2 = new Request(15, "请求2");
        handlerA.handleRequest(request2);

        Request request3 = new Request(25, "请求3");
        handlerA.handleRequest(request3);

        Request request4 = new Request(35, "请求4");
        handlerA.handleRequest(request4);
    }
}

        运行上述代码，输出结果如下：

ConcreteHandlerA 处理请求：请求1

ConcreteHandlerB 处理请求：请求2

ConcreteHandlerC 处理请求：请求3

没有处理器能处理该请求

        从这个示例可以看出，客户端创建了处理器链，并将请求传递给链的第一个处理器handlerA。每个具体处理器根据请求的级别判断是否处理，如果不能处理就传递给下一个处理器。当请求级别为 35 时，由于没有处理器能处理，就会输出 “没有处理器能处理该请求”。​

        这种实现方式使得处理器之间的耦合度极低，每个处理器只需要关注自己的处理逻辑和下一个处理器的引用，当需要新增或移除处理器时，只需调整链的结构即可，非常灵活。

 优缺点

优点

• 降低耦合度：这是责任链模式最显著的优点。它将请求的发送者和接收者完全解耦，发送者只需知道链的起点，无需了解后续的处理器是谁以及如何处理请求；接收者也只需关注自己职责范围内的请求处理，无需知道请求的来源和后续的传递情况。​这种解耦使得系统的各个部分可以独立地进行开发和维护。例如，在一个客户服务系统中，客户的咨询请求会经过自动回复、人工客服初级处理、人工客服高级处理等环节。当需要优化自动回复的逻辑时，不会影响到人工客服的处理流程；当新增一种处理环节时，也不需要修改客户发送请求的代码。​

• 简化了对象：由于对象不需要知道链的整体结构，只需知道链中下一个处理器的存在，这就简化了每个对象的设计，使其更加专注于自身的核心功能。​每个对象不需要存储整个链的信息，也不需要判断应该将请求发送给哪个具体的处理器，只需做好自己的本职工作，大大减少了对象的复杂性。就像在一个生产线上，每个工人只需要完成自己负责的工序，然后将产品传递给下一个工人，而不需要知道整个生产线的所有工序和工人。​

• 增强职责指派的灵活性：通过改变链内成员的组成或者调整它们的次序，可以动态地新增、删除责任，或者改变请求的处理流程，使系统具有更强的适应性和可扩展性。​在业务需求发生变化时，这种灵活性体现得尤为明显。比如在一个审批系统中，原本的审批流程是部门经理→总经理，当需要增加财务审批环节时，只需在部门经理和总经理之间加入财务经理处理器即可，不需要修改其他处理器的代码。​

• 便于增加新的请求处理类：当需要新增一种请求处理方式时，只需创建一个新的具体处理器类，并将其加入到责任链中合适的位置即可，无需修改原有系统的代码，符合 “开闭原则”。“开闭原则” 是软件设计的重要原则之一，它要求软件实体对扩展开放，对修改关闭。责任链模式很好地遵循了这一原则，使得系统能够在不破坏原有结构的情况下进行功能扩展，降低了系统的维护成本。

缺点

• 不能保证请求一定被接收：由于请求在链中传递，如果链中所有的处理器都无法处理该请求，那么请求将最终得不到处理，这可能会导致系统出现异常或错误。​为了避免这种情况，在实际应用中，通常需要在链的末尾设置一个默认处理器，当所有其他处理器都无法处理请求时，由默认处理器进行处理，比如给出错误提示或记录日志等。​

• 影响系统性能：请求需要在链中逐个传递，这会在一定程度上增加系统的开销，影响性能。而且在进行代码调试时，由于请求的传递路径不固定，可能会出现循环调用等问题，增加调试难度。​在处理器数量较多的情况下，请求的传递会消耗较多的时间和资源。此外，如果在设置处理器链时出现错误，导致处理器之间形成循环引用，就会出现请求在链中无限循环传递的情况，严重影响系统的正常运行。​

• 可能不容易观察运行时的特征：责任链的动态性使得在运行时很难清晰地追踪请求的处理过程和传递路径，不利于系统的除错和维护。​当系统出现问题时，开发人员需要花费更多的时间和精力去跟踪请求的流转过程，确定请求在哪个处理器中出现了问题。相比之下，一些结构固定的设计模式，其请求处理过程更加直观，便于调试和维护。

使用场景

• 当有多个对象可以处理同一请求，且具体哪个对象处理该请求需要由运行时刻自动确定时，责任链模式可以让请求在多个对象中流转，直到找到合适的处理者。

  • ​例如，在一个消息处理系统中，不同类型的消息需要由不同的消息处理器进行处理。文本消息、图片消息、视频消息等可能分别由对应的处理器处理，当一条消息进入系统时，系统无法预先知道它是哪种类型，通过责任链模式，消息会依次经过各个处理器，直到被对应的处理器处理。​

• 在不明确指定接收者的情况下，需要向多个对象中的一个提交一个请求时，责任链模式可以避免请求发送者与多个接收者之间的直接交互，通过链的形式实现请求的传递。

  • ​比如在一个设备监控系统中，监控中心需要将报警信息发送给相关的处理人员，但可能不确定具体由哪个人员处理。这时可以将处理人员按照一定的顺序组成一个责任链，报警信息在链中传递，直到有处理人员响应并处理该报警。​

• 当需要动态指定一组对象处理请求时，责任链模式可以方便地调整链的组成，满足动态变化的需求。​在一个任务调度系统中，任务的处理可能需要经过多个步骤，而这些步骤可能会根据任务的类型、优先级等因素动态变化。使用责任链模式，可以根据实际情况动态地添加或移除处理器，调整处理顺序，以适应不同任务的处理需求。

实际案例

JS 中的事件冒泡

        在 JavaScript 中，当一个 DOM 元素触发事件后，事件会从该元素开始，沿着 DOM 树向上依次传播给其父元素、祖父元素等，直到传播到文档对象。这一过程就类似于责任链模式，每个元素都有机会处理该事件，如果某个元素处理了事件并阻止了冒泡，那么事件就会停止传播；否则，事件会继续向上传递。​

        例如，在一个 HTML 页面中，有一个嵌套结构的元素：

<div id="grandparent">​
    <div id="parent">​
        <div id="child"></div>​
    </div>​
</div>

        为这三个元素分别绑定点击事件处理器：

document.getElementById('child').addEventListener('click', function(e) {
    console.log('child 被点击');
    // e.stopPropagation(); // 阻止事件冒泡
});

document.getElementById('parent').addEventListener('click', function() {
    console.log('parent 被点击');
});

document.getElementById('grandparent').addEventListener('click', function() {
    console.log('grandparent 被点击');
});

        当点击child元素时，如果不阻止事件冒泡，输出结果为：

child 被点击​

parent 被点击​

grandparent 被点击

        如果在child的事件处理器中调用e.stopPropagation()方法阻止事件冒泡，输出结果则为： 

child 被点击

        这里，child、parent、grandparent就构成了一条事件处理链，事件从child开始向上传递，每个元素的事件处理器都可以选择处理事件或让事件继续传递，这完全符合责任链模式的特征。 

 JAVA WEB 中 Apache Tomcat 对 Encoding 的处理

        在 Apache Tomcat 中，对于请求和响应的编码处理采用了责任链模式。一系列的编码处理器组成一条链，请求和响应在链中传递，每个处理器负责特定的编码转换工作，直到完成所有必要的编码处理。​

        Tomcat 的编码处理链包括Request对象的编码处理和Response对象的编码处理。当一个请求进入 Tomcat 容器时，请求数据会经过多个编码处理器的处理，比如 URL 编码解析、表单数据编码解析等。每个处理器会根据配置和请求的特征进行相应的编码转换，并将处理后的请求传递给下一个处理器。​

        这种处理方式使得 Tomcat 可以灵活地支持多种编码方式，并且可以根据需要新增或替换编码处理器，以适应不同的应用场景。

Struts2 的拦截器

        Struts2 框架中的拦截器是责任链模式的典型应用。拦截器链由多个拦截器组成，当一个请求到达 Action 之前，会依次经过拦截器链中的每个拦截器，每个拦截器可以对请求进行预处理；在 Action 执行完成后，请求会按照相反的顺序再次经过这些拦截器，进行后处理。​

        拦截器可以实现诸如参数验证、权限检查、日志记录等功能。例如，登录验证拦截器会检查用户是否已登录，如果未登录则跳转到登录页面；日志记录拦截器会记录请求的相关信息，如请求 URL、处理时间等。​

        通过拦截器链，Struts2 框架实现了功能的模块化和可插拔性，开发人员可以根据需要配置不同的拦截器，实现不同的功能组合。

JSP Servlet 的 Filter

        JSP Servlet 中的过滤器（Filter）也采用了责任链模式。多个过滤器组成一个过滤器链，请求在到达 Servlet 之前，会经过过滤器链中的每个过滤器，过滤器可以对请求进行过滤、修改等操作；同样，响应在返回客户端的过程中，也会经过过滤器链的处理。​

        过滤器可以用于实现很多功能，比如字符编码转换、敏感词过滤、压缩响应数据等。例如，字符编码过滤器可以将请求和响应的编码设置为指定的编码方式，避免出现乱码问题；敏感词过滤器可以检查请求参数中是否包含敏感词，如果包含则进行替换或拦截。​

        过滤器链的顺序可以通过配置文件进行设置，开发人员可以根据实际需求调整过滤器的执行顺序，灵活地实现过滤器链。下面是一个简单的字符编码过滤器示例：

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

@WebFilter(filterName = "EncodingFilter", urlPatterns = "/*")
public class EncodingFilter implements Filter {
    private String encoding;

    @Override
    public void init(FilterConfig filterConfig) throws ServletException {
        // 从配置文件中获取编码方式，默认使用UTF-8
        encoding = filterConfig.getInitParameter("encoding");
        if (encoding == null) {
            encoding = "UTF-8";
        }
    }

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        // 设置请求和响应的编码方式
        request.setCharacterEncoding(encoding);
        response.setCharacterEncoding(encoding);
        response.setContentType("text/html;charset=" + encoding);

        // 将请求传递给下一个过滤器或Servlet
        chain.doFilter(request, response);
    }

    @Override
    public void destroy() {
        // 释放资源
    }
}

        在这个示例中，EncodingFilter实现了Filter接口，在doFilter方法中设置了请求和响应的编码方式，然后通过chain.doFilter方法将请求传递给下一个组件。

总结​

        责任链模式作为一种重要的设计模式，通过将多个处理器对象连成一条链，实现了请求发送者与接收者的解耦，具有降低耦合度、简化对象、增强灵活性等优点。它在众多领域都有广泛的应用，如 JS 的事件冒泡、Apache Tomcat 的编码处理、Struts2 的拦截器、JSP Servlet 的 Filter 等。​

        然而，责任链模式也存在一些缺点，如不能保证请求一定被接收、影响系统性能、运行时特征难以观察等。在实际应用中，需要根据具体的业务需求，权衡其优缺点，合理地运用责任链模式。​

        同时，责任链模式的扩展与变体以及与其他设计模式的结合，使得它能够适应更加复杂和多样化的应用场景。通过不断地探索和实践，我们可以更好地发挥责任链模式的优势，设计出更加优秀、灵活和可维护的软件系统。