当前位置：首页 > article >正文

零基础设计模式——行为型模式 - 责任链模式

article 2025/6/12 18:38:38

第四部分：行为型模式 - 责任链模式 (Chain of Responsibility Pattern)

欢迎来到行为型模式的学习！行为型模式关注对象之间的职责分配、算法封装和对象间的交互。我们将学习的第一个行为型模式是责任链模式。

核心思想：使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。

责任链模式 (Chain of Responsibility Pattern)

“使多个对象都有机会处理请求，从而避免请求的发送者和接收者之间的耦合关系。将这些对象连成一条链，并沿着这条链传递该请求，直到有一个对象处理它为止。” (Avoid coupling the sender of a request to its receiver by giving more than one object a chance to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it.)

想象一下公司里的报销审批流程。一个员工提交了报销申请：

如果金额较小（比如500元以下），可能直接由其直属经理（第一个处理者）审批即可。
如果金额稍大（比如500元到2000元），直属经理审批后，还需要部门主管（第二个处理者）审批。
如果金额更大（比如2000元以上），部门主管审批后，可能还需要财务总监（第三个处理者）审批。

员工只需要提交申请，申请会沿着这条“审批链”传递，直到遇到能够完全处理它（或者批准，或者拒绝）的审批人，或者链条结束。

请求 (Request)：报销申请。
处理者 (Handler)：直属经理、部门主管、财务总监。
链 (Chain)：由这些审批人构成的审批顺序。

1. 目的 (Intent)

责任链模式的主要目的：

解耦发送者和接收者：请求的发送者不需要知道是哪个具体对象会处理它的请求。它只需要将请求发送到链的头部即可。
动态组合责任：可以动态地改变链中的处理者顺序或增删处理者，而无需修改客户端代码。
请求的灵活处理：每个处理者都可以决定自己是否处理该请求、是否将请求传递给下一个处理者，或者两者都做。

2. 生活中的例子 (Real-world Analogy)

客服电话系统：
- 你拨打客服电话，首先可能是一个自动语音应答系统（第一处理者）尝试解决你的问题。
- 如果解决不了，它会将你转接到初级人工客服（第二处理者）。
- 如果初级客服也无法解决，可能会转接到高级客服或技术支持（第三处理者）。
  你的问题沿着这条服务链传递，直到被解决。
异常处理机制 (try-catch-finally)：
- 在很多编程语言中，try 块中的代码如果抛出异常，会先被最近的 catch 块尝试捕获和处理。
- 如果第一个 catch 块不能处理该类型的异常，或者它选择重新抛出，异常会向上传播到外层的 catch 块（如果存在的话），形成一个异常处理链。
事件冒泡/捕获 (Event Bubbling/Capturing in Web Development)：
- 在HTML DOM中，当一个元素上发生事件（如点击），事件会从目标元素开始，逐级向上传播到其父元素，直到文档根节点（事件冒泡），或者从文档根节点向下传播到目标元素（事件捕获）。
- 每一级父元素都有机会处理这个事件。
中间件 (Middleware in Web Frameworks)：
- 像 Express.js, Django, ASP.NET Core 等Web框架中的中间件。一个HTTP请求会依次通过一系列注册的中间件（如日志记录、身份验证、数据压缩、路由处理等）。
- 每个中间件都可以处理请求、修改请求/响应，或者将请求传递给链中的下一个中间件。

3. 结构 (Structure)

责任链模式通常包含以下角色：

Handler (处理者接口/抽象类)：定义一个处理请求的接口。通常会包含一个指向链中下一个处理者的引用（successor）。它声明了一个处理请求的方法（如 handleRequest()）。
ConcreteHandler (具体处理者)：实现 Handler 接口。它负责处理它感兴趣的请求。如果它可以处理该请求，就处理之；否则，它会将请求转发给它的后继者。
Client (客户端)：创建处理者链，并发起请求到链上的某个处理者（通常是链的第一个处理者）。

工作流程：

客户端创建一个处理者链，并设置每个处理者的后继者。
客户端向链的第一个处理者发送请求。
处理者接收到请求后：
- 判断自己是否能处理该请求。
- 如果能处理，则处理请求。此时，它可以选择是否将请求继续传递给后继者（取决于具体需求，有些链在请求被处理后即终止，有些则允许继续传递）。
- 如果不能处理，则将请求传递给其后继者（如果后继者存在）。
请求沿着链传递，直到被某个处理者处理，或者到达链的末尾仍未被处理。

4. 适用场景 (When to Use)

有多个对象可以处理同一个请求，但具体由哪个对象处理则在运行时动态确定。
你想在不明确指定接收者的情况下，向多个对象中的一个提交一个请求。
需要动态指定一组对象处理请求的顺序。
当你想让请求的发送者和接收者解耦时。
当处理请求的对象集合应当动态指定时。

5. 优缺点 (Pros and Cons)

优点：

降低耦合度：请求的发送者和接收者之间解耦。发送者不需要知道谁将处理请求，也不需要知道链的结构。
增强了对象的指派职责的灵活性：可以通过改变链内的成员或者调动它们的次序，允许动态地新增或者删除责任。
增加新的请求处理类很方便：只需创建新的 Handler 类并将其加入链中即可，符合开闭原则。
每个处理者职责清晰：每个具体处理者只需要关注自己能处理的请求。

缺点：

请求不一定会被处理：由于请求在链上发送，如果链配置不当或者没有任何处理者能够处理该请求，请求可能会落空（到达链尾仍未被处理）。
不易观察运行时的特征：如果链条比较长，调试时可能不容易追踪请求的实际处理流程。
可能影响性能：请求需要从链头开始遍历，如果链过长，且大部分请求都需要由链尾的处理者处理，性能可能会受到影响。
链的创建和配置可能比较复杂：需要正确设置每个处理者的后继者。

6. 实现方式 (Implementations)

让我们以一个简单的日志系统为例。不同级别的日志消息（INFO, DEBUG, ERROR）由不同的记录器处理。

请求类 (LogRequest - 可选，或直接用参数)

这里我们直接用参数（日志级别和消息内容）传递，不单独创建请求类。

处理者接口 (Logger - Handler)

// logger.go (Handler interface)
package loggingconst (LevelInfo  = 1LevelDebug = 2LevelError = 3
)// Logger 处理者接口
type Logger interface {SetNext(logger Logger) Logger // 设置下一个处理者，并返回下一个处理者方便链式调用LogMessage(level int, message string) // 处理日志消息write(message string) // 具体的写日志方法，由具体处理者实现
}

// Logger.java (Handler abstract class)
package com.example.logging;public abstract class Logger {public static final int INFO = 1;public static final int DEBUG = 2;public static final int ERROR = 3;protected int level; // 当前处理器能处理的级别protected Logger nextLogger; // 责任链中的下一个元素public Logger setNextLogger(Logger nextLogger) {this.nextLogger = nextLogger;return this.nextLogger; // 返回下一个logger，方便链式设置}public void logMessage(int level, String message) {if (this.level <= level) { // 如果当前处理器的级别允许处理该消息write(message);}if (nextLogger != null) { // 如果有下一个处理器，则传递下去nextLogger.logMessage(level, message);}}// 抽象方法，由子类实现具体的日志写入操作abstract protected void write(String message);
}

具体处理者 (InfoLogger, DebugLogger, ErrorLogger - ConcreteHandler)

// abstract_logger.go (Base for Concrete Handlers - Go doesn't have abstract classes, use struct embedding)
package logging// AbstractLogger 基础结构，包含下一个处理者的引用
type AbstractLogger struct {level    intnext     Logger
}func (al *AbstractLogger) SetNext(logger Logger) Logger {al.next = loggerreturn logger
}// LogMessage 默认实现：如果级别匹配则自己写，然后传递给下一个
func (al *AbstractLogger) LogMessage(level int, message string) {if al.level <= level {al.write(message) // 调用具体实现类的 write}if al.next != nil {al.next.LogMessage(level, message)}
}// write 是一个需要被具体 Logger 实现的方法，但由于 Go 的限制，
// 我们不能在这里定义一个抽象的 write。具体 Logger 需要自己实现 write，
// 并在 LogMessage 中调用它，或者像上面那样，让 AbstractLogger 的 LogMessage 调用一个 write 方法，
// 这个 write 方法必须是具体 Logger 类型的一部分。
// 为了简单，我们让具体 Logger 实现 Logger 接口，并在 LogMessage 中直接调用自己的 write。
// 或者，我们可以让具体 Logger 嵌入 AbstractLogger，并重写 LogMessage 或提供 write。// --- 具体实现 ---// info_logger.go
package loggingimport "fmt"type InfoLogger struct {AbstractLogger
}func NewInfoLogger(level int) *InfoLogger {il := &InfoLogger{}il.AbstractLogger.level = levelreturn il
}// write 实现具体的日志写入逻辑
func (il *InfoLogger) write(message string) {fmt.Println("INFO Logger: " + message)
}// LogMessage (可以重写以改变行为，例如只处理自己的级别然后停止)
// 如果不重写，则使用 AbstractLogger 的 LogMessage 行为// debug_logger.go
package loggingimport "fmt"type DebugLogger struct {AbstractLogger
}func NewDebugLogger(level int) *DebugLogger {dl := &DebugLogger{}dl.AbstractLogger.level = levelreturn dl
}func (dl *DebugLogger) write(message string) {fmt.Println("DEBUG Logger: " + message)
}// error_logger.go
package loggingimport "fmt"type ErrorLogger struct {AbstractLogger
}func NewErrorLogger(level int) *ErrorLogger {el := &ErrorLogger{}el.AbstractLogger.level = levelreturn el
}func (el *ErrorLogger) write(message string) {fmt.Println("ERROR Logger: " + message)
}

注意：在Go的实现中，由于没有传统意义的抽象方法，AbstractLogger 的 LogMessage 调用 al.write(message)。这意味着嵌入 AbstractLogger 的具体类型必须有一个名为 write 的方法。如果具体类型也想改变 LogMessage 的传递逻辑（例如，处理后就停止），则需要重写 LogMessage 方法。

一个更符合责任链“要么处理要么传递”的Go实现方式，可能是在LogMessage中判断是否能处理，如果不能，则直接调用next.LogMessage。如果能处理，则处理，然后根据策略决定是否继续传递。

修改后的Go AbstractLogger 和具体实现：

// logger.go (Handler interface - 修正版)
package loggingconst (LevelInfo  = 1LevelDebug = 2LevelError = 3
)type Logger interface {SetNext(logger Logger) LoggerProcessLog(level int, message string) // 改名为 ProcessLog，更清晰
}// abstract_logger.go (Base for Concrete Handlers - 修正版)
package logging// AbstractLogger 基础结构
type AbstractLogger struct {level intnext  Logger
}func (al *AbstractLogger) SetNext(logger Logger) Logger {al.next = loggerreturn logger
}// ProcessLog 模板方法：如果当前级别能处理，则调用 write，否则传递
// 注意：这里的 write 仍然需要具体类型实现。我们将让具体类型重写 ProcessLog。
// 或者，我们可以让 write 成为接口的一部分，但这样每个具体实现都需要检查级别。
// 更常见的做法是，每个具体 Handler 的处理方法自己决定是否处理和是否传递。// --- 具体实现 (修正版) ---// info_logger.go
package loggingimport "fmt"type InfoLogger struct {level intnext  Logger
}func NewInfoLogger(level int) *InfoLogger {return &InfoLogger{level: level}
}func (il *InfoLogger) SetNext(logger Logger) Logger {il.next = loggerreturn logger
}func (il *InfoLogger) ProcessLog(level int, message string) {if il.level <= level {fmt.Println("INFO Logger: " + message)}if il.next != nil {il.next.ProcessLog(level, message)}
}// debug_logger.go
package loggingimport "fmt"type DebugLogger struct {level intnext  Logger
}func NewDebugLogger(level int) *DebugLogger {return &DebugLogger{level: level}
}func (dl *DebugLogger) SetNext(logger Logger) Logger {dl.next = loggerreturn logger
}func (dl *DebugLogger) ProcessLog(level int, message string) {if dl.level <= level {fmt.Println("DEBUG Logger: " + message)}if dl.next != nil {dl.next.ProcessLog(level, message)}
}// error_logger.go
package loggingimport "fmt"type ErrorLogger struct {level intnext  Logger
}func NewErrorLogger(level int) *ErrorLogger {return &ErrorLogger{level: level}
}func (el *ErrorLogger) SetNext(logger Logger) Logger {el.next = loggerreturn logger
}func (el *ErrorLogger) ProcessLog(level int, message string) {if el.level <= level {fmt.Println("ERROR Logger: " + message)}if el.next != nil {el.next.ProcessLog(level, message)}
}

// InfoLogger.java (ConcreteHandler)
package com.example.logging;public class InfoLogger extends Logger {public InfoLogger(int level) {this.level = level;}@Overrideprotected void write(String message) {System.out.println("INFO Logger: " + message);}
}// DebugLogger.java (ConcreteHandler)
package com.example.logging;public class DebugLogger extends Logger {public DebugLogger(int level) {this.level = level;}@Overrideprotected void write(String message) {System.out.println("DEBUG Logger: " + message);}
}// ErrorLogger.java (ConcreteHandler)
package com.example.logging;public class ErrorLogger extends Logger {public ErrorLogger(int level) {this.level = level;}@Overrideprotected void write(String message) {System.out.println("ERROR Logger: " + message);}
}

客户端使用

// main.go (示例用法)
/*
package mainimport ("./logging""fmt"
)func getChainOfLoggers() logging.Logger {errorLogger := logging.NewErrorLogger(logging.LevelError)debugLogger := logging.NewDebugLogger(logging.LevelDebug)infoLogger := logging.NewInfoLogger(logging.LevelInfo)// 构建责任链: Error -> Debug -> Info// 意味着 ErrorLogger 是链的开始，如果它处理不了或选择传递，则给 DebugLogger，以此类推// 但在这个日志例子中，通常是 Info (最低级) -> Debug -> Error (最高级)// 并且每个logger都会打印它能处理的级别以及更高级别的日志// 更常见的日志链: Info -> Debug -> Error// InfoLogger 处理所有 INFO, DEBUG, ERROR// DebugLogger 处理所有 DEBUG, ERROR (如果从 InfoLogger 传递过来)// ErrorLogger 处理所有 ERROR (如果从 DebugLogger 传递过来)infoLogger.SetNext(debugLogger)debugLogger.SetNext(errorLogger)return infoLogger // 返回链的头部
}func main() {loggerChain := getChainOfLoggers()fmt.Println("--- Sending INFO message ---")loggerChain.ProcessLog(logging.LevelInfo, "This is an information.")// Expected: INFO, DEBUG, ERROR loggers might print this if their level <= LevelInfo// With our current logger logic (this.level <= level), and chain Info -> Debug -> Error:// InfoLogger (level 1 <= 1) prints.// DebugLogger (level 2 > 1) does not print itself, but passes.// ErrorLogger (level 3 > 1) does not print itself.// Corrected logic for typical logging: a logger handles messages AT OR ABOVE its configured level.// So, if chain is Info(1) -> Debug(2) -> Error(3):// LevelInfo message: InfoLogger prints. DebugLogger and ErrorLogger also print.// LevelDebug message: InfoLogger does not print. DebugLogger prints. ErrorLogger prints.// LevelError message: InfoLogger and DebugLogger do not print. ErrorLogger prints.// The example code implements: if my_handler_level <= message_level, then I print.// This means a higher level handler (e.g. ErrorLogger with level 3) will print for a lower level message (e.g. Info with level 1).// This is typical for logging frameworks where setting a log level (e.g. INFO) means you see INFO and all levels above it (DEBUG, ERROR).fmt.Println("\n--- Sending DEBUG message ---")loggerChain.ProcessLog(logging.LevelDebug, "This is a debug level information.")// Expected (with chain Info(1) -> Debug(2) -> Error(3) and handler_level <= message_level):// InfoLogger (1 <= 2) prints.// DebugLogger (2 <= 2) prints.// ErrorLogger (3 > 2) does not print itself.fmt.Println("\n--- Sending ERROR message ---")loggerChain.ProcessLog(logging.LevelError, "This is an error information.")// Expected (with chain Info(1) -> Debug(2) -> Error(3) and handler_level <= message_level):// InfoLogger (1 <= 3) prints.// DebugLogger (2 <= 3) prints.// ErrorLogger (3 <= 3) prints.// Let's clarify the Go logger logic for a more standard CoR where only one handler acts// or where a handler acts and then passes. The current Go example is more like a broadcast// to all eligible handlers based on level comparison.// A more CoR-like logger might be: each logger handles ONLY its specific level.// If so, the chain order and logic in ProcessLog would change.// Example: if level == il.level { print } else if next != nil { next.ProcessLog }
}
*/

// Main.java (示例用法)
/*
package com.example;import com.example.logging.Logger;
import com.example.logging.InfoLogger;
import com.example.logging.DebugLogger;
import com.example.logging.ErrorLogger;public class Main {private static Logger getChainOfLoggers() {// 创建不同级别的日志记录器Logger errorLogger = new ErrorLogger(Logger.ERROR);Logger debugLogger = new DebugLogger(Logger.DEBUG);Logger infoLogger = new InfoLogger(Logger.INFO);// 构建责任链// INFO logger is the first in chain, then DEBUG, then ERROR.// A message of a certain level will be handled by loggers whose level is less than or equal to the message's level.infoLogger.setNextLogger(debugLogger);debugLogger.setNextLogger(errorLogger);return infoLogger; // 返回链的头部}public static void main(String[] args) {Logger loggerChain = getChainOfLoggers();System.out.println("--- Sending INFO message ---");loggerChain.logMessage(Logger.INFO, "This is an information.");// Expected output (based on current Java Logger logic):// INFO Logger: This is an information.// (DEBUG and ERROR loggers will also be called but won't print if their level is higher than INFO)// Corrected: With `this.level <= level`, InfoLogger (1<=1) prints. DebugLogger (2>1) no, ErrorLogger (3>1) no.// The Java code's logMessage passes to nextLogger REGARDLESS of whether current logger wrote.// So, for INFO message (level 1):// InfoLogger (level 1): write() called. nextLogger.logMessage(1, ...) called.// DebugLogger (level 2): write() NOT called (2 > 1). nextLogger.logMessage(1, ...) called.// ErrorLogger (level 3): write() NOT called (3 > 1). nextLogger is null.// Output: INFO Logger: This is an information.System.out.println("\n--- Sending DEBUG message ---");loggerChain.logMessage(Logger.DEBUG, "This is a debug level information.");// For DEBUG message (level 2):// InfoLogger (level 1): write() called. nextLogger.logMessage(2, ...) called.// DebugLogger (level 2): write() called. nextLogger.logMessage(2, ...) called.// ErrorLogger (level 3): write() NOT called (3 > 2). nextLogger is null.// Output: INFO Logger: This is a debug level information.//         DEBUG Logger: This is a debug level information.System.out.println("\n--- Sending ERROR message ---");loggerChain.logMessage(Logger.ERROR, "This is an error information.");// For ERROR message (level 3):// InfoLogger (level 1): write() called. nextLogger.logMessage(3, ...) called.// DebugLogger (level 2): write() called. nextLogger.logMessage(3, ...) called.// ErrorLogger (level 3): write() called. nextLogger is null.// Output: INFO Logger: This is an error information.//         DEBUG Logger: This is an error information.//         ERROR Logger: This is an error information.}
}
*/

关于日志示例的说明：
上面的日志示例实现了一种“广播式”的责任链，即一个日志消息会被所有级别低于或等于该消息级别的记录器处理。例如，一个 ERROR 消息会被 InfoLogger、DebugLogger 和 ErrorLogger 都记录（如果它们都在链中且按此顺序）。

一个更“纯粹”的责任链变体可能是：

单一处理：一旦一个处理者处理了请求，请求就不再向下传递。
条件传递：处理者处理请求后，根据某些条件决定是否继续传递。

例如，在审批流程中，一旦经理批准了小额报销，就不需要再给总监看。这需要在 handleRequest 方法中加入逻辑：如果处理了，则返回或不再调用 successor.handleRequest()。

对于日志，当前实现是合理的，因为通常希望高优先级的日志也包含低优先级日志记录器的输出（例如，设置日志级别为DEBUG，则INFO和DEBUG日志都可见）。

7. 总结

责任链模式通过将多个能够处理请求的对象连接成一条链，使得请求可以在链上动态传递，直到被处理为止。它有效地解耦了请求的发送者和接收者，并允许动态地组织和修改处理者链。这种模式在需要多个对象协同处理一个请求，并且具体处理者在运行时确定的场景中非常有用，如审批流程、事件处理、中间件管道等。

记住它的核心：请求沿链传递，逐级处理，解耦收发。