登录
首页 >  文章 >  java教程

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

时间:2026-01-21 12:07:02 299浏览 收藏

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

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

Java命令模式与责任链模式的核心概念

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); // 明确委托,不隐式跳转
        }
    }
}

两者混用时最常踩的坑:链里塞命令,还是命令里藏链?

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

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

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

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

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

前往漫画官网入口并下载 ➜
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>