命令模式与责任链模式详解

哈喽！大家好，很高兴又见面了，我是golang学习网的一名作者，今天由我给大家带来一篇《命令模式与责任链模式核心解析》，本文主要会讲到等等知识点，希望大家一起学习进步，也欢迎大家关注、点赞、收藏、转发! 下面就一起来看看吧！

命令模式解耦请求结构，责任链模式解耦处理流程；前者封装请求为对象以支持撤销/排队，后者动态拼接处理器决定是否传递请求；混用需分层避免职责混乱。

Java 中命令模式和责任链模式解决的是两类完全不同的问题，不能混用，也别强行组合——除非你明确知道中间那层解耦代价是什么。

命令模式的核心是「把请求封装成对象」

它让调用者（Invoker）不直接操作接收者（Receiver），而是通过 Command 对象间接触发行为。关键在于：每个 Command 实例都持有对具体接收者和具体动作的引用，且必须实现统一接口（如 execute()、undo()）。

常见错误是把 Command 写成纯函数式接口（比如只传 Runnable），丢失了状态保持能力——这样就无法支持撤销、重做、排队或日志记录。

实操建议：

• Command 类应包含接收者引用（不是静态工具类）、必要参数、以及可选的 undo() 实现
• 避免在 execute() 里写业务逻辑分支；分支应由不同 Command 子类承担
• 如果命令需要异步执行，应在 Invoker 层处理线程调度，而非塞进 Command 自身

public interface Command {
    void execute();
    void undo();
}

public class LightOnCommand implements Command {
    private final Light light; // 接收者实例，非 static

    public LightOnCommand(Light light) {
        this.light = light;
    }

    @Override
    public void execute() {
        light.turnOn();
    }

    @Override
    public void undo() {
        light.turnOff();
    }
}

责任链模式的核心是「动态拼接处理节点」

它让多个处理器（Handler）组成一条链，请求沿着链传递，每个节点决定是否处理、是否继续向下传。重点不在“谁处理”，而在“谁有权决定是否终止传递”。

典型误用是把责任链写成固定顺序的 if-else if-else 链——这根本不是责任链，只是条件分支；真正的链必须支持运行时增删节点、跳过中间节点、甚至循环回溯（虽然不推荐）。

实操建议：

• 每个 Handler 必须持有下一个 Handler 的引用（next），而不是靠外部硬编码顺序
• 不要在 handle() 里直接 new 下一个 handler；链的组装应在客户端完成
• 警惕空指针：next == null 是链尾，不是 bug，应明确设计默认行为（如抛异常 / 返回空 / 记录告警）

public abstract class Handler {
    protected Handler next;

    public void setNext(Handler next) {
        this.next = next;
    }

    public abstract void handle(Request request);
}

public class AuthHandler extends Handler {
    @Override
    public void handle(Request request) {
        if (!request.isValidToken()) {
            throw new SecurityException("Invalid token");
        }
        if (next != null) {
            next.handle(request); // 明确委托，不隐式跳转
        }
    }
}

两者混用时最常踩的坑：链里塞命令，还是命令里藏链？

有人试图用责任链管理命令执行顺序（比如先校验、再持久化、最后发消息），结果把 Command 和 Handler 职责搅在一起：既想封装请求，又想控制流程走向。这时往往出现两个问题：

• 撤销逻辑失效：责任链中途断掉，前面已执行的 Command 没法统一回滚
• 节点复用困难：一个 Handler 如果同时承担命令执行和链路控制，就很难被其他场景复用

更合理的做法是分层：用责任链做前置拦截（权限、参数、限流），链末端才触发命令执行器；或者用命令队列 + 独立的责任链处理器来处理命令的生命周期事件（如“命令提交后通知审计模块”）。

真正难的不是写对单个模式，而是判断当前需求到底要解耦「请求结构」，还是要解耦「处理流程」——前者选命令，后者选责任链。边界模糊时，先画出调用时序图，看箭头是从谁指向谁、中间有没有可插拔的决策点。

本篇关于《命令模式与责任链模式详解》的介绍就到此结束啦，但是学无止境，想要了解学习更多关于文章的相关知识，请关注golang学习网公众号！