在本文中，我们将详细讲解Java设计模式中的责任链模式，探讨其基本概念、使用场景、常见问题和解决方式。同时，我们还会介绍责任链模式与策略模式的区别，并结合电商交易系统的示例进行说明。此外，我们还会探讨责任链模式在开源框架中的应用。
1. 责任链模式概述
责任链模式是一种行为设计模式，旨在将请求沿着链传递，直到被某个处理器处理。它使得多个对象都有机会处理请求，避免了请求发送者与接收者的耦合。
1.1 主要特点
- 请求传递：请求沿着链条依次传递，直到找到能够处理该请求的处理器。
- 灵活性：可以动态增加或删除处理器，调整处理链的顺序。
- 解耦：请求发送者和处理者之间没有直接的依赖关系。
1.2 结构
责任链模式主要包括以下几个角色：
- Handler：定义了处理请求的接口，并包含了对下一个处理器的引用。
- ConcreteHandler：具体的处理器类，负责处理具体的请求。
- Client：发出请求的客户端，依赖于Handler接口。
2. 使用场景
- 请求需要多个对象进行处理：例如，在订单处理系统中，不同的订单状态可能由不同的处理器进行处理。
- 动态的请求处理链：如审批流程，处理链可以根据业务需求进行动态配置。
3. 电商交易系统中的示例
以电商交易系统为例，我们将演示如何使用责任链模式来处理订单状态的变化。例如，订单可能会经历"已支付"、"已发货"、"已收货"等状态，每个状态的处理都可以看作是责任链中的一个环节。
3.1 错误示范
在没有使用责任链模式的情况下，订单状态的处理可能会写成一长串的if-else语句，这样的代码可读性差，维护困难。
public class OrderService {
public void processOrder(Order order) {
if (order.getStatus().equals("PAID")) {
// 处理已支付的订单
} else if (order.getStatus().equals("SHIPPED")) {
// 处理已发货的订单
} else if (order.getStatus().equals("DELIVERED")) {
// 处理已收货的订单
}
// 其他状态处理
}
}
3.2 正确示范
使用责任链模式可以将不同状态的处理分离到各自的处理器中，增强代码的灵活性和可维护性。
abstract class OrderHandler {
protected OrderHandler nextHandler;
public void setNextHandler(OrderHandler nextHandler) {
this.nextHandler = nextHandler;
}
public abstract void handleOrder(Order order);
}
class PaidOrderHandler extends OrderHandler {
@Override
public void handleOrder(Order order) {
if (order.getStatus().equals("PAID")) {
// 处理已支付的订单
} else if (nextHandler != null) {
nextHandler.handleOrder(order);
}
}
}
class ShippedOrderHandler extends OrderHandler {
@Override
public void handleOrder(Order order) {
if (order.getStatus().equals("SHIPPED")) {
// 处理已发货的订单
} else if (nextHandler != null) {
nextHandler.handleOrder(order);
}
}
}
class DeliveredOrderHandler extends OrderHandler {
@Override
public void handleOrder(Order order) {
if (order.getStatus().equals("DELIVERED")) {
// 处理已收货的订单
} else if (nextHandler != null) {
nextHandler.handleOrder(order);
}
}
}
使用责任链模式后，我们可以灵活地添加、删除或调整处理器顺序，无需修改现有代码。
3.3 类图
4. 常见问题与解决方式
4.1 问题一：责任链过长导致性能问题
在某些场景下，责任链可能会变得过长，导致每次请求传递的效率低下。
解决方式：
- 优化链条顺序：将最常用的处理器放在链条前面。
- 分拆责任链：将责任链拆分成多个子链，分别处理不同的请求。
4.2 问题二：处理器无法处理请求
当所有处理器都无法处理请求时，可能会导致请求被忽略。
解决方式：
-
添加默认处理器：在链的末尾添加一个默认的处理器，处理无法被处理的请求。
class DefaultOrderHandler extends OrderHandler {
@Override
public void handleOrder(Order order) {
// 处理无法处理的请求
}
}
5. 责任链模式与策略模式的区别
责任链模式与策略模式都是行为型模式，但它们的使用场景和目的有所不同。
- 责任链模式：关注请求的传递，通过一系列的处理器逐个处理请求。适用于多个对象依次处理请求的场景。
- 策略模式：关注算法的替换，通过定义一组算法类来实现相同的功能。适用于需要动态切换算法的场景。
6. 责任链模式在开源框架中的应用
责任链模式在许多开源框架中得到了广泛应用，例如Spring Security中的过滤器链就是责任链模式的典型应用。
6.1 Spring Security过滤器链简介
Spring Security是一个为Java企业应用提供安全功能的框架。它的核心之一就是过滤器链，用来对请求进行认证和授权。每个请求在进入应用程序之前，都会经过一组过滤器。每个过滤器依次处理请求，完成特定的安全检查任务，如身份验证、权限检查、跨站点请求伪造（CSRF）防护等。
这些过滤器形成了一个"责任链"，请求在链上一个一个过滤器中传递，直到某个过滤器处理完毕或整个链处理结束。
Spring Security的过滤器链是基于Servlet API中的javax.servlet.Filter接口构建的。该接口的核心方法是doFilter()，它接受请求和响应作为参数，并负责将请求传递给链中的下一个过滤器。
6.2 责任链模式的应用结构
在责任链模式中，通常会有以下几个角色：
- 处理者（Handler）： 定义一个处理请求的接口。每个具体的处理者实现该接口来处理部分请求。
- 具体处理者（Concrete Handler）： 处理链中实际的处理器，处理请求或将请求传递给下一个处理者。
- 客户（Client）： 发起请求的对象，不关心谁处理了请求，也不需要知道具体的处理者。
在Spring Security中，处理者相当于Filter，而具体处理者是各种具体的安全过滤器，如UsernamePasswordAuthenticationFilter、BasicAuthenticationFilter等。客户是HTTP请求。
6.3 Spring Security责任链模式工作流程
当客户端请求到达Spring Security的过滤器链时，过滤器链按照顺序执行每一个过滤器，直到某个过滤器决定阻止请求继续处理或最后一个过滤器处理完请求。
流程大致如下：
- 客户端发起请求：请求首先被交给第一个过滤器处理。
- 过滤器链依次执行 ：每个过滤器执行其
doFilter()方法，执行安全检查。 - 请求传递：如果当前过滤器无法处理请求，或者处理完毕后仍需进一步检查，则将请求传递给下一个过滤器。
- 终止或继续：若某个过滤器决定终止请求（例如认证失败），则直接返回响应，不再执行后续过滤器；否则，继续传递请求。
- 最后一个过滤器完成处理：所有过滤器执行完毕后，若没有过滤器拦截请求，则请求到达目标资源。
6.4 案例：自定义过滤器链
现在我们通过一个实际的案例，演示如何在Spring Security中使用自定义过滤器链。假设我们需要在现有的Spring Security过滤器链中增加一个自定义的认证过滤器，用来处理特殊的请求认证逻辑。
步骤1：创建自定义过滤器 我们首先创建一个继承自OncePerRequestFilter的过滤器，并在其中实现自定义的认证逻辑。
import javax.servlet.FilterChain;
import javax.servlet.ServletException;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.web.filter.OncePerRequestFilter;
import java.io.IOException;
public class CustomAuthenticationFilter extends OncePerRequestFilter {
@Override
protected void doFilterInternal(HttpServletRequest request,
HttpServletResponse response,
FilterChain filterChain)
throws ServletException, IOException {
String token = request.getHeader("Authorization");
// 简单的认证逻辑：如果存在token，就通过认证
if (token != null && token.startsWith("Bearer ")) {
// 模拟将用户信息存入SecurityContext
SecurityContextHolder.getContext().setAuthentication(
new CustomAuthenticationToken(token));
}
// 继续传递请求到下一个过滤器
filterChain.doFilter(request, response);
}
}
在这个过滤器中，我们从HTTP请求的头部获取Authorization信息，并检查它是否以Bearer 开头。如果符合条件，就将认证信息存储在SecurityContextHolder中。之后，调用filterChain.doFilter()将请求继续传递给下一个过滤器。
步骤2：配置自定义过滤器链
接下来，我们需要将自定义的过滤器加入到Spring Security的过滤器链中。通过扩展WebSecurityConfigurerAdapter并重写configure方法，我们可以将自定义过滤器插入到合适的位置。
import org.springframework.context.annotation.Configuration;
import org.springframework.security.config.annotation.web.builders.HttpSecurity;
import org.springframework.security.config.annotation.web.configuration.WebSecurityConfigurerAdapter;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
@Configuration
public class SecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http
.addFilterBefore(new CustomAuthenticationFilter(), UsernamePasswordAuthenticationFilter.class)
.authorizeRequests()
.anyRequest().authenticated();
}
}
在此配置中，我们使用了addFilterBefore()方法，将自定义的CustomAuthenticationFilter添加到UsernamePasswordAuthenticationFilter之前。这样，自定义过滤器将会在用户名密码认证过滤器之前执行。
步骤3：测试过滤器链
至此，过滤器链已经配置完成。我们可以通过HTTP请求来测试我们的过滤器链是否正常工作。
curl -H "Authorization: Bearer abc123" http://localhost:8080/api/orders
当客户端发送带有Authorization头的请求时，自定义过滤器会处理认证逻辑，随后将请求继续传递给下一个过滤器。如果认证通过，Spring Security将允许访问资源，否则将会返回未认证错误。
通过这种设计，Spring Security可以灵活地配置过滤器的顺序和内容，增强系统的可扩展性。
7. 总结
责任链模式在处理复杂的请求传递场景中非常有效，尤其是在需要灵活调整处理顺序的系统中。通过本篇文章的介绍，你应该已经掌握了责任链模式的基本概念、使用场景、常见问题以及如何在实际项目中应用它