责任链模式（Chain of Responsibility Pattern）是一种行为型设计模式，它允许多个对象按照顺序处理请求，并且每个对象可以选择自己是否处理该请求或将其传递给下一个对象。这种模式将请求的发送者和接收者解耦，同时提供了更大的灵活性和可扩展性。
简介
责任链模式通过将多个处理请求的对象组成一条链，使请求在链上传递，直到有一个对象处理它为止。每个处理对象都负责判断自己能否处理该请求，如果可以则进行处理，否则将请求传递给下一个处理对象。这样，请求发送者无需知道具体的处理对象，只需将请求发送到责任链上即可。
责任链模式包含以下角色：
- 抽象处理者（Handler）：定义一个处理请求的接口，并持有下一个处理者的引用。
- 具体处理者（Concrete Handler）：实现抽象处理者的接口，在处理请求前判断自己是否能够处理该请求，如果可以则进行处理，否则将请求传递给下一个处理者。
通过责任链模式，我们可以动态地组合处理对象，灵活地配置处理流程，这种解耦使得系统更加灵活和可扩展。
使用场景
责任链模式常用于以下场景：
- 动态组合处理流程：通过灵活配置责任链，可以动态地组合处理对象，实现不同的处理流程。每个处理者只需关注自己负责处理的请求，使得系统更加灵活和可扩展。
- 避免请求的发送者和接收者之间的直接耦合：通过将请求传递给责任链，请求发送者无需知道具体的处理对象，减少了对象之间的依赖关系。
- 处理请求的顺序可变：责任链模式允许在运行时根据需要改变处理请求的顺序，灵活调整处理流程。
常见的实际应用场景包括：
- 日志记录器链：一个日志记录系统可以根据日志级别将日志消息传递给不同的日志记录器，如控制台记录器、文件记录器、数据库记录器等。
- 审批流程：一个多级审批系统可以根据审批者的权限和级别将审批请求传递给下一个级别的审批者，直到获得最终的审批结果。
- 异常处理：一个异常处理系统可以根据异常类型将异常进行分类处理，如日志记录、邮件通知、异常展示等。
责任链模式在这些场景中可以减少代码的耦合性，提高代码的可维护性和可扩展性。
优缺点
优点：
- 解耦发送者和接收者：责任链模式将请求的发送者和接收者解耦，发送者无需知道具体的处理对象，只需将请求发送到责任链上即可。
- 灵活动态的处理流程：通过配置责任链，可以灵活地组合处理对象，实现不同的处理流程，并且可以在运行时动态地改变处理的顺序。
- 增强代码的可扩展性：由于责任链模式遵循开闭原则，新的处理者可以随时被加入到责任链中，不需要修改已有代码，提供了良好的扩展性。
- 增强代码的可维护性：每个处理者只需关注自己负责处理的请求，职责单一，使得代码更加清晰、可读性更高。
缺点：
- 请求的处理不保证被处理：由于责任链中的每个处理者都可以选择是否处理请求，如果没有正确配置责任链或者某个处理者没有正确处理请求，可能会导致请求无法被处理。
- 性能问题：当责任链过长或者请求在责任链中被频繁传递时，可能会对性能产生影响。因此，在设计责任链时需要注意链的长度和处理的复杂度。
- 调试不方便：当责任链特别是链条比较长， 环节比较多的时候，由于采用了类似递归的方式，调试的时候逻辑可能比较复杂。
在实际应用中，我们需要根据具体情况评估责任链模式的优缺点，并合理地选择使用或者改进这个模式。
责任链模式实现
要实现责任链模式，我们按照以下步骤进行：
以下是一个简单的示例，演示如何使用责任链模式处理请假申请：
步骤一：定义处理者接口（Handler）
/**
*
* 责任链模式——抽象类处理器
*
*/
public abstract class AbstractHandler {
/**
* 责任链中的下一个元素
*/
protected AbstractHandler nextHandler;
public AbstractHandler setNextChain(AbstractHandler nextHandler) {
this.nextHandler = nextHandler;
return nextHandler;
}
/**
* 责任链处理逻辑
*/
public void linkChain(LeaveRequest request) {
handler(request);
//这里还可以加入其他方法
if (Objects.nonNull(nextHandler)) {
nextHandler.linkChain(request);
}
}
/**
* 抽象方法
*/
protected abstract void handler(LeaveRequest request);
}请求对象为：
@Getter
public class LeaveRequest {
private final String employee;
private final int days;
public LeaveRequest(String employee, int days) {
this.employee = employee;
this.days = days;
}
}步骤二：实现具体处理者类（ConcreteHandler）
@Slf4j
public class Handler1 extends AbstractHandler {
@Override
public void handler(LeaveRequest request) {
if (request.getDays() 3 && request.getDays() 7) {
log.info("ConcreteHandlerC 处理了 " + request.getEmployee() + " 的请假申请，天数为：" + request.getDays());
}
}
}步骤三：在客户端代码中创建责任链，并将请求发送到责任链上的第一个处理者
public class ChainPatternDemo {
private static AbstractHandler getChainOfHandler() {
AbstractHandler handler1 = new Handler1();
AbstractHandler handler2 = new Handler2();
AbstractHandler handler3 = new Handler3();
//可以自定义链路顺序
handler1.setNextChain(handler2).setNextChain(handler3);
return handler1;
}
public static void main(String[] args) {
AbstractHandler chain = getChainOfHandler();
LeaveRequest request1 = new LeaveRequest("张三", 2);
chain.linkChain(request1);
LeaveRequest request2 = new LeaveRequest("李四", 5);
chain.linkChain(request2);
LeaveRequest request3 = new LeaveRequest("王五", 10);
chain.linkChain(request3);
}
}在上述示例中，我们定义了三个具体处理者类：Handler1、Handler2和Handler3，它们分别处理请假申请。客户端代码创建了责任链，并将请求发送给第一个处理者Handler1。每个具体处理者判断自己是否能够处理该请求，如果可以则进行处理，否则传递给下一个处理者。
运行以上代码，输出结果为：
ConcreteHandlerA 处理了 张三 的请假申请，天数为：2
ConcreteHandlerB 处理了 李四 的请假申请，天数为：5
ConcreteHandlerC 处理了 王五 的请假申请，天数为：10这只是一个简单示例，实际使用时可以根据业务需求进行适当的扩展和修改。
在使用责任链模式时，需要注意以下几点：
- 确定责任链中的处理顺序：要确保责任链中处理者的顺序是正确的，以便能够按照预期处理请求。处理者的顺序可以在创建责任链时进行设置。
- 避免出现循环引用：如果责任链中的处理者之间出现了循环引用，可能会导致请求无法被正确处理或进入死循环。因此，在设置下一个处理者时要注意避免出现循环引用的情况。
- 处理者的数量控制：在设计责任链时要注意控制处理者的数量，避免责任链过长导致性能下降。可以根据实际需求合理划分责任链，将相关的处理逻辑放在同一个处理者中，可以在 Handler 中设置一个最大节点数量，在 setNextChain() 方法中判断是否已经是超过其阈值，超过则不允许该链建立，避免无意识地破坏系统性能。
通过建造者模式优化
我们可以通过建造者模式来创建责任链中的处理者对象。这种优化可以使责任链的创建和配置更加灵活和可拓展，符合开闭原则。
优化后的示例代码：
/**
*
* 责任链模式——抽象类处理器
*
*/
public abstract class AbstractHandler {
/**
* 责任链中的下一个元素
*/
protected AbstractHandler nextHandler;
private void setNextChain(AbstractHandler nextHandler) {
this.nextHandler = nextHandler;
}
/**
* 责任链处理逻辑
*/
public void linkChain(LeaveRequest request) {
handler(request);
//这里还可以加入其他方法
if (Objects.nonNull(nextHandler)) {
nextHandler.linkChain(request);
}
}
/**
* 抽象方法
*/
protected abstract void handler(LeaveRequest request);
public static class Builder {
private AbstractHandler head;
private AbstractHandler tail;
public Builder addHandler(AbstractHandler handler) {
if (this.head == null) {
this.head = this.tail = handler;
return this;
}
this.tail.setNextChain(handler);
this.tail = handler;
return this;
}
public AbstractHandler build() {
return this.head;
}
}
}public class ChainPatternDemo {
private static AbstractHandler getChainOfHandler() {
return new AbstractHandler.Builder()
.addHandler(new Handler1())
.addHandler(new Handler2())
.addHandler(new Handler3())
.build();
}
public static void main(String[] args) {
AbstractHandler chain = getChainOfHandler();
LeaveRequest request1 = new LeaveRequest("张三", 2);
chain.linkChain(request1);
LeaveRequest request2 = new LeaveRequest("李四", 5);
chain.linkChain(request2);
LeaveRequest request3 = new LeaveRequest("王五", 10);
chain.linkChain(request3);
}
}在客户端代码中，我们使用建造者模式创建了一个包含多个处理者的责任链，并发送了一个请假申请。责任链会按照添加处理者的顺序依次处理请假申请，直到找到能够处理该请求的处理者为止。
通过调用 addHandler 方法，我们可以逐步构建责任链，将处理者添加到责任链的末尾，由于 setNextChain() 不对外调用，作用域可以更改为 private，最后，通过调用 build 方法，我们可以获取责任链的起始处理者。
Spring中使用责任链模式
Spring中我们可以使用 @Component，@Order 注解，来让容器帮我们自动构建责任链，从而简化代码。
public abstract class Handler {
abstract void handler(LeaveRequest request);
}@Order(value = 1)
@Component
@Slf4j
public class HandlerA extends Handler{
@Override
public void handler(LeaveRequest request) {
if (request.getDays() 3 && request.getDays() 7) {
log.info("ConcreteHandlerC 处理了 " + request.getEmployee() + " 的请假申请，天数为：" + request.getDays());
}
}
}测试：
@Test
public void test() {
for (Handler handler : handlerChain) {
LeaveRequest request = new LeaveRequest("王五", 10);
handler.handler(request);
}
}输出：
ConcreteHandlerC 处理了 王五 的请假申请，天数为：10这种写法有其利弊，优点是可以避免繁琐的责任链构建过程，简化了代码结构；缺点是具体处理者类之间的执行顺序不够直观，具体使用时需要权衡考虑。
责任链模式的优点在于其低耦合性、灵活性和可扩展性，使得我们能够更加轻松地管理和组织复杂的处理流程。然而，也要注意其缺点，即请求未必被处理和对处理顺序敏感的特点。
最重要的是，在实际应用中根据具体需求合理运用责任链模式，结合其他设计模式，以便在代码结构和可维护性上取得更好的效果。
