聊到设计模式里的命令模式我经常碰到来面试的同学说“知道这个概念但一让写代码就卡壳”或者项目里需要加个撤销功能第一时间想到用命令模式却又不知道从哪下手。今天这篇就专门把命令模式掰开揉碎从最核心的思想讲起一步步写出完整的Java实现最后再聊聊那些文档里不写但实操必踩的坑。无论你是刚学Java设计模式的新手还是在准备面试、做代码重构的老手这篇都能帮你把命令模式彻底用起来。命令模式说白了就是“把请求封装成对象”。听起来很抽象但等你真正理解并动手写一遍代码之后你会发现它其实特别接地气——很多框架比如Runnable、Undo/Redo、事务回滚背后都有它的影子。我会用厨师和点菜单的例子把概念讲透然后给出完整的Java代码实现包括命令接口、具体命令、调用者、接收者最后再补上撤销、宏命令这些进阶玩法让这篇文章可以当作一份能直接拿去实践的命令模式项目笔记来用。1. 命令模式整体设计与思路拆解1.1 为什么需要命令模式从“紧耦合”到“松耦合”的转变我们先看一个最常见的反面教材。假如你在写一个智能家居控制系统里面有灯、空调、电视每个设备都有各自的开和关操作。最直觉的写法是public class Light { public void on() { System.out.println(灯亮了); } public void off() { System.out.println(灯灭了); } }然后在控制器里直接调用这些具体方法public class SimpleController { private Light light; public void pressButton(String action) { if (on.equals(action)) { light.on(); } else if (off.equals(action)) { light.off(); } } }这样写有什么问题控制器直接依赖了具体的Light类如果明天要增加一个风扇、一个摄像头控制器里的if-else就会越来越多越来越难维护。更致命的是控制器的“按键”逻辑和设备的具体操作完全绑死你没法把“开灯”这个动作保存下来、传给别人、排队执行更没法做撤销。命令模式解决的就是这一整类问题。它的核心思路是把“动作”本身抽象成一个独立的对象——我不直接告诉你“去把灯打开”而是给你一个封装了“把灯打开”这个请求的Command对象。调用者不关心这个命令到底是谁执行的、怎么执行的只负责触发命令接收者也不关心是谁调用的只负责执行自己的业务逻辑。这样调用者和接收者之间就彻底解耦了。1.2 核心思想落地点餐单与厨师的类比用生活里的场景来类比命令模式就像你去餐厅点餐。你客户不会直接跑进后厨告诉厨师“给我炒个菜”因为那样后厨会被各种人直接打扰而且你也没法保存“我要点什么”这个请求。真实流程是你把需求写在菜单命令上服务员调用者拿着菜单交给后厨厨师接收者根据菜单执行具体的做菜动作。菜单本身可以被记录、可以排队、甚至可以被收回撤销。餐厅换个厨师对你的点餐方式没有任何影响因为菜单这个“命令对象”已经把你和具体做菜的人解耦了。这个类比对应的角色是命令接口Command定义了统一的 execute 方法相当于菜单的格式“菜名做法”。具体命令ConcreteCommand封装了“某个接收者做某件事”的绑定关系相当于“鱼香肉丝”这张菜单上写明“交给李厨做”。接收者Receiver真正干活的对象相当于厨师它知道怎么做菜。调用者Invoker持有命令并触发执行相当于服务员只管传单和喊“上菜”。客户端Client负责创建具体命令并绑定接收者相当于你点菜时把需求写进菜单。这种设计的优势非常明显新增一种操作只需要新增一个具体命令类完全不需要改动调用者代码。拿“开风扇”举例只要写一个FanOnCommand实现Command接口在构造时传入Fan对象然后把它塞给调用者就行了。原有代码一行不用改符合开闭原则。2. 命令模式核心细节解析与实操要点2.1 四个角色的职责边界与代码约定在实际写代码之前一定要先把四个角色的边界分清楚否则写着写着就容易把代码写成“命令模式”和“策略模式”的杂交体最后四不像。先看命令接口Java里面最简单的定义public interface Command { void execute(); }有些场景还需要支持撤销所以在接口里加一个undo方法public interface Command { void execute(); void undo(); }这里有个关键的设计决策undo要不要放在接口里。我的建议是如果项目里明确有撤销需求就放进去如果没有不要为了“面向未来的扩展”去增加所有命令类的实现负担。YAGNI原则在模式实现里同样适用等真正需要的时候再抽取一个支持撤销的接口也不迟。接收者Receiver是真正干活的类它不需要实现任何命令接口只需要提供自己的业务方法。举个例子public class Light { private boolean on false; public void on() { on true; System.out.println(灯亮了); } public void off() { on false; System.out.println(灯灭了); } }注意接收者完全不知道命令模式的存在它是一个纯业务类。这一点特别重要很多新手会把业务逻辑写进命令类里导致接收者成了空壳命令类越来越胖违背了命令模式分离关注点的初衷。具体命令ConcreteCommand是核心它必须持有接收者引用并在execute方法里调用接收者的方法public class LightOnCommand implements Command { private Light light; public LightOnCommand(Light light) { this.light light; } Override public void execute() { light.on(); } Override public void undo() { light.off(); } }每次创建一个具体命令都要在构造时注入它需要的接收者这是命令模式和策略模式最容易混淆的地方。策略模式关注的是“算法可以换”调用者传入不同的策略对象命令模式关注的是“动作可以封装、排队、撤销”调用者持有命令对象但不知道里面封装了什么。调用者Invoker负责持有命令并触发执行它不需要在乎命令内部是干什么的public class RemoteControl { private Command command; public void setCommand(Command command) { this.command command; } public void pressButton() { command.execute(); } }这个类越简单越好它就是一个“发令枪”。如果你往调用者里面塞各种业务判断它就会退回到那个满是if-else的控制器老路上去。2.2 参数化与延迟执行命令模式的隐藏能力很多人以为命令模式只是把方法调用包了一层好像没什么大不了的。但它的价值在于你在“导致行为的方法调用”和“真正执行行为的那一瞬间”之间插入了一个对象。有了这层对象你可以把命令存起来、传给别的方法、放到队列里排队执行甚至通过网络传输到另一台机器上执行。这就是命令模式的隐藏能力——参数化和延迟执行。参数化体现在调用者可以随时切换不同的命令对象同一个按键绑定了开灯命令就是开灯绑定了关灯命令就是关灯。客户端在运行时可以动态决定这个按键的功能这种灵活性是直接耦合设备对象做不到的。延迟执行体现在命令执行前你可以把命令对象塞进一个集合里等某个时机触发再逐一调用execute。比如游戏的技能系统玩家按下一串技能快捷键系统先把这些技能封装成命令对象放进队列然后在下一帧统一执行。用户界面上的每一个按钮点击也可以被封装成命令然后放到一个待处理的队列里由后台线程慢慢执行。为了展示这种能力我扩展一下遥控器让它支持多个插槽和撤销import java.util.Stack; public class RemoteControl { private Command[] onCommands; private Command[] offCommands; private StackCommand undoStack new Stack(); public RemoteControl(int slots) { onCommands new Command[slots]; offCommands new Command[slots]; Command noCommand new NoCommand(); for (int i 0; i slots; i) { onCommands[i] noCommand; offCommands[i] noCommand; } } public void setCommand(int slot, Command onCommand, Command offCommand) { onCommands[slot] onCommand; offCommands[slot] offCommand; } public void pressOnButton(int slot) { onCommands[slot].execute(); undoStack.push(onCommands[slot]); } public void pressOffButton(int slot) { offCommands[slot].execute(); undoStack.push(offCommands[slot]); } public void pressUndoButton() { if (!undoStack.isEmpty()) { Command command undoStack.pop(); command.undo(); } } }这里有一个小细节我定义了一个NoCommand空命令类它什么都不做用来避免空指针判断。这是空对象模式的应用在很多开源框架里都很常见。不要小看它它能让代码干净很多。3. 实操过程与核心环节实现一个完整可运行的项目3.1 项目场景设定与搭建既然标题是“从思想到代码实现”那我们就直接撸一个能跑起来的完整小项目。我设定一个多槽位智能遥控器场景它能控制灯光、风扇支持撤销操作。这个项目涵盖了命令模式最核心的几点命令接口、具体命令、调用者、客户端装配、撤销。先建包结构我用的是纯JDK环境没有引入任何第三方依赖方便你直接复制到本地运行src/ ├── command/ │ ├── Command.java │ ├── NoCommand.java │ ├── LightOnCommand.java │ ├── LightOffCommand.java │ ├── FanHighCommand.java │ └── FanOffCommand.java ├── receiver/ │ ├── Light.java │ └── Fan.java ├── invoker/ │ └── RemoteControl.java └── client/ └── RemoteLoader.java接收者类我加入一个风扇风扇有多个档位用整数表示速度0停转1低速2高速。撤销时恢复到前一个档位。这个状态记录逻辑是命令模式撤销功能里最需要留心的地方。package receiver; public class Fan { public static final int OFF 0; public static final int LOW 1; public static final int HIGH 2; private int speed OFF; public void high() { speed HIGH; System.out.println(风扇高速转动); } public void low() { speed LOW; System.out.println(风扇低速转动); } public void off() { speed OFF; System.out.println(风扇停了); } public int getSpeed() { return speed; } }注意接收者为了支持撤销自己保存了speed状态命令类需要读取这个状态来记住“前一个状态”。更严谨的做法是命令类自己保存前一个状态但那样会让命令类持有过多状态。这两种方案各有利弊我现在展示的是接收者自己维护状态命令撤销时直接调用接收者的历史状态恢复方法。为了撤销得更完整我给Fan加一个setSpeed方法并在具体命令里记录上一个速度package receiver; public class Fan { public static final int OFF 0; public static final int LOW 1; public static final int HIGH 2; private int speed OFF; public void high() { setSpeed(HIGH); System.out.println(风扇高速转动); } public void low() { setSpeed(LOW); System.out.println(风扇低速转动); } public void off() { setSpeed(OFF); System.out.println(风扇停了); } public void setSpeed(int speed) { this.speed speed; } public int getSpeed() { return speed; } }然后让具体命令在执行前记录前一个状态package command; import receiver.Fan; public class FanHighCommand implements Command { private Fan fan; private int prevSpeed; public FanHighCommand(Fan fan) { this.fan fan; } Override public void execute() { prevSpeed fan.getSpeed(); fan.high(); } Override public void undo() { fan.setSpeed(prevSpeed); System.out.println(风扇恢复到速度 prevSpeed); } }3.2 客户端装配与完整演示最后写客户端把各个命令对象装配到遥控器的插槽上这个阶段叫“配置”通常由系统启动时一次性完成package client; import command.FanHighCommand; import command.FanOffCommand; import command.LightOffCommand; import command.LightOnCommand; import command.NoCommand; import invoker.RemoteControl; import receiver.Fan; import receiver.Light; public class RemoteLoader { public static void main(String[] args) { RemoteControl remote new RemoteControl(2); Light livingRoomLight new Light(); Fan ceilingFan new Fan(); LightOnCommand livingRoomLightOn new LightOnCommand(livingRoomLight); LightOffCommand livingRoomLightOff new LightOffCommand(livingRoomLight); FanHighCommand fanHigh new FanHighCommand(ceilingFan); FanOffCommand fanOff new FanOffCommand(ceilingFan); remote.setCommand(0, livingRoomLightOn, livingRoomLightOff); remote.setCommand(1, fanHigh, fanOff); // 操作演示 remote.pressOnButton(0); remote.pressOffButton(0); remote.pressUndoButton(); // 撤销关灯灯应该重新亮起 remote.pressOnButton(1); remote.pressUndoButton(); // 撤销风扇高速风扇应恢复到之前状态 } }这里有个值得品味的点remote.pressOnButton(0)执行的是“开灯”命令pressOffButton(0)执行的是“关灯”命令而pressUndoButton不直接调用接收者它只是从栈里取出最后一条命令并调用它的undo方法。整个过程里RemoteControl 对 Light、Fan 一无所知它只跟 Command 接口打交道。这就是“调用者与接收者解耦”的直观体现。运行这段代码输出应该是灯亮了 灯灭了 灯亮了 风扇高速转动 风扇恢复到速度 0完整代码还算精简但它已经把命令模式的全部关键点都覆盖了。你把这段代码跑通再去看Spring里那些基于命令模式思想的实现或者Netty的ChannelHandler链思路会清晰很多。4. 常见问题与排查技巧实录4.1 撤销功能里的状态保存最容易翻车的地方我在实际项目里见过最典型的撤销实现错误是把“撤销”写成了“再次执行”。原因就是命令对象的undo方法里没有保存执行前的状态直接在undo里调用了接收者的某个反向方法一旦业务逻辑有多个分支撤销就会出乱子。比如刚才的风扇有人可能会这么写undoOverride public void undo() { fan.off(); // 错误示范 }这种写法只在“命令是从off状态来的”情况下成立。如果执行FanHighCommand之前风扇本来就是low撤销时直接off状态就错了。正确做法一定是在execute时先把前一个状态存下来程序员要记住撤销的核心是“恢复执行前”不是“变为相反的”。如果接收者有多个互斥状态比如灯的开/关、风扇的off/low/high请务必在execute方法里先记录prevState然后在undo里用setPrevState恢复。这种方式虽然多写几行代码但逻辑可靠得多。4.2 空命令与异常处理几个隐蔽的坑第一个坑插槽没有绑定命令时直接调用会抛空指针。解决办法就是我在第3节里提到的NoCommand空对象。很多框架源码里都有这种类别觉得它多余它能帮你省掉无数个if (command ! null)判断。第二个坑命令对象生命周期过长。如果你的命令对象被放到队列或历史栈中它持有的接收者引用也会一直存活。如果在Web应用里用命令模式做异步任务接收者本身是有状态且重量级的对象小心内存泄漏。这时候接收者应该设计得足够轻或者命令对象在执行完后主动释放接收者引用。第三个坑execute方法内部如果抛了异常undo栈要不要记录这没有唯一正确答案。我个人的经验是如果execute没有完成状态变更就不应该入栈如果执行到一半抛异常最好先保证接收者状态回滚到执行前再决定是否入栈。简单起见可以在execute里用try-catch包住业务逻辑状态没变更成功就不push到undo栈。4.3 与策略模式、观察者模式的辨析面试高频题之一命令模式和策略模式有什么区别我给一个很直白的判断标准策略模式关注“怎么做”命令模式关注“做什么”。策略模式里Context持有策略对象运行时替换算法命令模式里Invoker持有命令对象触发执行并且命令对象可以保存、排队、撤销。你看Runnable接口它更像命令模式因为任务被封装起来延迟执行而Comparator它显然是策略模式因为排序算法可以替换。观察者模式则通常理解为“发布-订阅”主题状态变化时通知观察者观察者的update方法由主题统一触发。命令模式更主动调用者决定什么时候、以什么方式触发命令。两者本质上都实现了发布方与接收方的解耦但观察者模式的通知逻辑是主题内部的命令模式的动作触发则是外部注入的。理解到这一层你在系统设计里就不会用错。5. 命令模式在真实项目里的典型应用与扩展5.1 事务与日志回滚从演示到企业级实践很多人以为命令模式只是教学玩具但其实它是很多企业级框架的底层思想。比如数据库事务你可以把每条SQL操作封装成一个命令对象执行时记录日志回滚时逆向执行undo。Java里最典型的例子是Swing的Action和UndoManager以及Spring的事务模板里对回滚的处理方式。再举一个我参与过的真实业务场景一个配置中心管理员批量修改设备配置。每一条修改都是一条命令把这些命令按顺序执行同时持久化到一张命令日志表。如果某一条命令执行失败系统自动把前面已经执行的命令全部undo一遍从而保证批量操作的原子性。这种设计用if-else逐条处理会很难维护但用命令模式天然就是“命令集合 日志 顺序回滚”的组合代码结构清晰得让人舒服。如果你想把命令模式用于日志系统可以给命令接口增加一个store()或load()方法支持把命令序列化保存到文件或数据库。Java的序列化机制或者JSON序列化都能派上用场。这样系统重启后还能恢复上次未完成的命令队列这就是“持久化命令”的概念。5.2 宏命令与组合使用命令的分层艺术宏命令就是用一个命令对象封装一组子命令执行宏命令时按顺序执行所有子命令。这有点像宏录制你按下“录制”键后续操作都被封装成命令对象收集起来按下“播放”键依次执行宏内所有命令。实现宏命令特别简单就是组合模式与命令模式的结合package command; import java.util.ArrayList; import java.util.List; public class MacroCommand implements Command { private ListCommand commands new ArrayList(); public void addCommand(Command command) { commands.add(command); } Override public void execute() { for (Command command : commands) { command.execute(); } } Override public void undo() { // 逆序撤销 for (int i commands.size() - 1; i 0; i--) { commands.get(i).undo(); } } }注意撤销顺序必须逆序比如宏命令是“开灯开风扇”撤销时应该先关风扇再关灯否则结果和预期不一致。这个细节我在接手别人代码时发现过好几次十有八九都是正序撤销然后状态全乱。宏命令的价值在于把多个命令聚合成一个语义化命令。比如UI里的“一键回家”按钮点击后执行关灯、关空调、开摄像头、锁门四条命令你只需要把它封装成一个MacroCommand按钮绑定它即可。以后要调整流程改宏命令内部组合就行按钮代码完全不用动。5.3 队列与线程池中的命令模式因为命令对象封装了“动作接收者”天然适合扔到队列里由线程池异步执行。我做过一个文件批量转换工具每个文件转换任务就是一个命令对象包含输入路径、输出路径、转换器接收者。把任务提交给线程池主线程不用等待还能统一控制队列长度和失败重试。这里有个关键点命令对象必须是可序列化的至少不可变否则多线程环境下易燃易爆。我的经验是命令对象的字段都用final修饰接收者尽量无状态或者接收者本身就是线程安全的服务类。否则就算命令模式思想再优雅多线程下照样翻车。6. 进阶心得与实际项目决策建议6.1 写在最后什么时候该用什么时候别用我个人在使用命令模式时有一条判断标准如果这段业务代码只被调用一次也没有保存、排队、撤销的需求那就没有必要硬套命令模式。设计模式不是勋章堆得越多越高级它能解决问题才算有价值。命令模式最适用的场景是需要把“动作”作为一等公民来处理比如撤销、事务、队列、宏命令。聊聊我在实际项目里的一个反面教训。之前有个同事在一个非常简单的查询接口里套了命令模式一个查询流程拆出了六个类QueryCommand、QueryReceiver、QueryInvoker……本来二十行的业务逻辑硬生生膨胀成了二十个文件后来维护的人查代码查得怀疑人生。设计模式的正确姿态是“按需引入”先写简洁直接的代码等出现重复的调用逻辑、撤销需求、队列需求时再逐步重构到命令模式。不要为了用模式而用模式这一点我踩过坑希望你能直接避开。6.2 给新手的练习路径建议如果你想把命令模式牢固掌握我建议按这个顺序去练先照着本文代码跑通遥控器项目理解四个角色的关系。给项目增加一个“电视”接收者实现电视的开、关、切换频道命令练习新增代码不修改已有类。自测撤销功能开灯 - 关灯 - 撤销看状态是否正确风扇先开高速再开低速再撤销看是否恢复到高速而不是停止。自己封装一个宏命令把“回家模式”和“离家模式”各做成一条宏命令。最后把命令模式用到你自己的小项目里比如做一个简单的文本编辑器封装“插入文字”“删除文字”两个命令实现CtrlZ撤销。练完这五步你对命令模式的理解会和只看概念完全不同。代码这种东西不动手永远是纸面知识。最后分享一个小技巧在跑这些练习的时候给每个命令类加一个toString方法把接收者名称和动作类型打印出来方便调试时一眼看出当前按的到底是哪条命令。别小看这个调试习惯我之前在排查撤销顺序问题时就是靠日志里打印的命令顺序定位到正序撤销的bug的。命令模式是一个入门门槛低但进阶空间大的模式它连接着面向对象设计的很多核心思想封装变化、单一职责、开闭原则。把这一篇里的代码吃透再去看Spring的事务管理、Java的Runnable机制、以及各种UI框架的Action体系你会觉得很多地方都似曾相识。
命令模式从思想到Java实现：完整代码与实战避坑指南
聊到设计模式里的命令模式我经常碰到来面试的同学说“知道这个概念但一让写代码就卡壳”或者项目里需要加个撤销功能第一时间想到用命令模式却又不知道从哪下手。今天这篇就专门把命令模式掰开揉碎从最核心的思想讲起一步步写出完整的Java实现最后再聊聊那些文档里不写但实操必踩的坑。无论你是刚学Java设计模式的新手还是在准备面试、做代码重构的老手这篇都能帮你把命令模式彻底用起来。命令模式说白了就是“把请求封装成对象”。听起来很抽象但等你真正理解并动手写一遍代码之后你会发现它其实特别接地气——很多框架比如Runnable、Undo/Redo、事务回滚背后都有它的影子。我会用厨师和点菜单的例子把概念讲透然后给出完整的Java代码实现包括命令接口、具体命令、调用者、接收者最后再补上撤销、宏命令这些进阶玩法让这篇文章可以当作一份能直接拿去实践的命令模式项目笔记来用。1. 命令模式整体设计与思路拆解1.1 为什么需要命令模式从“紧耦合”到“松耦合”的转变我们先看一个最常见的反面教材。假如你在写一个智能家居控制系统里面有灯、空调、电视每个设备都有各自的开和关操作。最直觉的写法是public class Light { public void on() { System.out.println(灯亮了); } public void off() { System.out.println(灯灭了); } }然后在控制器里直接调用这些具体方法public class SimpleController { private Light light; public void pressButton(String action) { if (on.equals(action)) { light.on(); } else if (off.equals(action)) { light.off(); } } }这样写有什么问题控制器直接依赖了具体的Light类如果明天要增加一个风扇、一个摄像头控制器里的if-else就会越来越多越来越难维护。更致命的是控制器的“按键”逻辑和设备的具体操作完全绑死你没法把“开灯”这个动作保存下来、传给别人、排队执行更没法做撤销。命令模式解决的就是这一整类问题。它的核心思路是把“动作”本身抽象成一个独立的对象——我不直接告诉你“去把灯打开”而是给你一个封装了“把灯打开”这个请求的Command对象。调用者不关心这个命令到底是谁执行的、怎么执行的只负责触发命令接收者也不关心是谁调用的只负责执行自己的业务逻辑。这样调用者和接收者之间就彻底解耦了。1.2 核心思想落地点餐单与厨师的类比用生活里的场景来类比命令模式就像你去餐厅点餐。你客户不会直接跑进后厨告诉厨师“给我炒个菜”因为那样后厨会被各种人直接打扰而且你也没法保存“我要点什么”这个请求。真实流程是你把需求写在菜单命令上服务员调用者拿着菜单交给后厨厨师接收者根据菜单执行具体的做菜动作。菜单本身可以被记录、可以排队、甚至可以被收回撤销。餐厅换个厨师对你的点餐方式没有任何影响因为菜单这个“命令对象”已经把你和具体做菜的人解耦了。这个类比对应的角色是命令接口Command定义了统一的 execute 方法相当于菜单的格式“菜名做法”。具体命令ConcreteCommand封装了“某个接收者做某件事”的绑定关系相当于“鱼香肉丝”这张菜单上写明“交给李厨做”。接收者Receiver真正干活的对象相当于厨师它知道怎么做菜。调用者Invoker持有命令并触发执行相当于服务员只管传单和喊“上菜”。客户端Client负责创建具体命令并绑定接收者相当于你点菜时把需求写进菜单。这种设计的优势非常明显新增一种操作只需要新增一个具体命令类完全不需要改动调用者代码。拿“开风扇”举例只要写一个FanOnCommand实现Command接口在构造时传入Fan对象然后把它塞给调用者就行了。原有代码一行不用改符合开闭原则。2. 命令模式核心细节解析与实操要点2.1 四个角色的职责边界与代码约定在实际写代码之前一定要先把四个角色的边界分清楚否则写着写着就容易把代码写成“命令模式”和“策略模式”的杂交体最后四不像。先看命令接口Java里面最简单的定义public interface Command { void execute(); }有些场景还需要支持撤销所以在接口里加一个undo方法public interface Command { void execute(); void undo(); }这里有个关键的设计决策undo要不要放在接口里。我的建议是如果项目里明确有撤销需求就放进去如果没有不要为了“面向未来的扩展”去增加所有命令类的实现负担。YAGNI原则在模式实现里同样适用等真正需要的时候再抽取一个支持撤销的接口也不迟。接收者Receiver是真正干活的类它不需要实现任何命令接口只需要提供自己的业务方法。举个例子public class Light { private boolean on false; public void on() { on true; System.out.println(灯亮了); } public void off() { on false; System.out.println(灯灭了); } }注意接收者完全不知道命令模式的存在它是一个纯业务类。这一点特别重要很多新手会把业务逻辑写进命令类里导致接收者成了空壳命令类越来越胖违背了命令模式分离关注点的初衷。具体命令ConcreteCommand是核心它必须持有接收者引用并在execute方法里调用接收者的方法public class LightOnCommand implements Command { private Light light; public LightOnCommand(Light light) { this.light light; } Override public void execute() { light.on(); } Override public void undo() { light.off(); } }每次创建一个具体命令都要在构造时注入它需要的接收者这是命令模式和策略模式最容易混淆的地方。策略模式关注的是“算法可以换”调用者传入不同的策略对象命令模式关注的是“动作可以封装、排队、撤销”调用者持有命令对象但不知道里面封装了什么。调用者Invoker负责持有命令并触发执行它不需要在乎命令内部是干什么的public class RemoteControl { private Command command; public void setCommand(Command command) { this.command command; } public void pressButton() { command.execute(); } }这个类越简单越好它就是一个“发令枪”。如果你往调用者里面塞各种业务判断它就会退回到那个满是if-else的控制器老路上去。2.2 参数化与延迟执行命令模式的隐藏能力很多人以为命令模式只是把方法调用包了一层好像没什么大不了的。但它的价值在于你在“导致行为的方法调用”和“真正执行行为的那一瞬间”之间插入了一个对象。有了这层对象你可以把命令存起来、传给别的方法、放到队列里排队执行甚至通过网络传输到另一台机器上执行。这就是命令模式的隐藏能力——参数化和延迟执行。参数化体现在调用者可以随时切换不同的命令对象同一个按键绑定了开灯命令就是开灯绑定了关灯命令就是关灯。客户端在运行时可以动态决定这个按键的功能这种灵活性是直接耦合设备对象做不到的。延迟执行体现在命令执行前你可以把命令对象塞进一个集合里等某个时机触发再逐一调用execute。比如游戏的技能系统玩家按下一串技能快捷键系统先把这些技能封装成命令对象放进队列然后在下一帧统一执行。用户界面上的每一个按钮点击也可以被封装成命令然后放到一个待处理的队列里由后台线程慢慢执行。为了展示这种能力我扩展一下遥控器让它支持多个插槽和撤销import java.util.Stack; public class RemoteControl { private Command[] onCommands; private Command[] offCommands; private StackCommand undoStack new Stack(); public RemoteControl(int slots) { onCommands new Command[slots]; offCommands new Command[slots]; Command noCommand new NoCommand(); for (int i 0; i slots; i) { onCommands[i] noCommand; offCommands[i] noCommand; } } public void setCommand(int slot, Command onCommand, Command offCommand) { onCommands[slot] onCommand; offCommands[slot] offCommand; } public void pressOnButton(int slot) { onCommands[slot].execute(); undoStack.push(onCommands[slot]); } public void pressOffButton(int slot) { offCommands[slot].execute(); undoStack.push(offCommands[slot]); } public void pressUndoButton() { if (!undoStack.isEmpty()) { Command command undoStack.pop(); command.undo(); } } }这里有一个小细节我定义了一个NoCommand空命令类它什么都不做用来避免空指针判断。这是空对象模式的应用在很多开源框架里都很常见。不要小看它它能让代码干净很多。3. 实操过程与核心环节实现一个完整可运行的项目3.1 项目场景设定与搭建既然标题是“从思想到代码实现”那我们就直接撸一个能跑起来的完整小项目。我设定一个多槽位智能遥控器场景它能控制灯光、风扇支持撤销操作。这个项目涵盖了命令模式最核心的几点命令接口、具体命令、调用者、客户端装配、撤销。先建包结构我用的是纯JDK环境没有引入任何第三方依赖方便你直接复制到本地运行src/ ├── command/ │ ├── Command.java │ ├── NoCommand.java │ ├── LightOnCommand.java │ ├── LightOffCommand.java │ ├── FanHighCommand.java │ └── FanOffCommand.java ├── receiver/ │ ├── Light.java │ └── Fan.java ├── invoker/ │ └── RemoteControl.java └── client/ └── RemoteLoader.java接收者类我加入一个风扇风扇有多个档位用整数表示速度0停转1低速2高速。撤销时恢复到前一个档位。这个状态记录逻辑是命令模式撤销功能里最需要留心的地方。package receiver; public class Fan { public static final int OFF 0; public static final int LOW 1; public static final int HIGH 2; private int speed OFF; public void high() { speed HIGH; System.out.println(风扇高速转动); } public void low() { speed LOW; System.out.println(风扇低速转动); } public void off() { speed OFF; System.out.println(风扇停了); } public int getSpeed() { return speed; } }注意接收者为了支持撤销自己保存了speed状态命令类需要读取这个状态来记住“前一个状态”。更严谨的做法是命令类自己保存前一个状态但那样会让命令类持有过多状态。这两种方案各有利弊我现在展示的是接收者自己维护状态命令撤销时直接调用接收者的历史状态恢复方法。为了撤销得更完整我给Fan加一个setSpeed方法并在具体命令里记录上一个速度package receiver; public class Fan { public static final int OFF 0; public static final int LOW 1; public static final int HIGH 2; private int speed OFF; public void high() { setSpeed(HIGH); System.out.println(风扇高速转动); } public void low() { setSpeed(LOW); System.out.println(风扇低速转动); } public void off() { setSpeed(OFF); System.out.println(风扇停了); } public void setSpeed(int speed) { this.speed speed; } public int getSpeed() { return speed; } }然后让具体命令在执行前记录前一个状态package command; import receiver.Fan; public class FanHighCommand implements Command { private Fan fan; private int prevSpeed; public FanHighCommand(Fan fan) { this.fan fan; } Override public void execute() { prevSpeed fan.getSpeed(); fan.high(); } Override public void undo() { fan.setSpeed(prevSpeed); System.out.println(风扇恢复到速度 prevSpeed); } }3.2 客户端装配与完整演示最后写客户端把各个命令对象装配到遥控器的插槽上这个阶段叫“配置”通常由系统启动时一次性完成package client; import command.FanHighCommand; import command.FanOffCommand; import command.LightOffCommand; import command.LightOnCommand; import command.NoCommand; import invoker.RemoteControl; import receiver.Fan; import receiver.Light; public class RemoteLoader { public static void main(String[] args) { RemoteControl remote new RemoteControl(2); Light livingRoomLight new Light(); Fan ceilingFan new Fan(); LightOnCommand livingRoomLightOn new LightOnCommand(livingRoomLight); LightOffCommand livingRoomLightOff new LightOffCommand(livingRoomLight); FanHighCommand fanHigh new FanHighCommand(ceilingFan); FanOffCommand fanOff new FanOffCommand(ceilingFan); remote.setCommand(0, livingRoomLightOn, livingRoomLightOff); remote.setCommand(1, fanHigh, fanOff); // 操作演示 remote.pressOnButton(0); remote.pressOffButton(0); remote.pressUndoButton(); // 撤销关灯灯应该重新亮起 remote.pressOnButton(1); remote.pressUndoButton(); // 撤销风扇高速风扇应恢复到之前状态 } }这里有个值得品味的点remote.pressOnButton(0)执行的是“开灯”命令pressOffButton(0)执行的是“关灯”命令而pressUndoButton不直接调用接收者它只是从栈里取出最后一条命令并调用它的undo方法。整个过程里RemoteControl 对 Light、Fan 一无所知它只跟 Command 接口打交道。这就是“调用者与接收者解耦”的直观体现。运行这段代码输出应该是灯亮了 灯灭了 灯亮了 风扇高速转动 风扇恢复到速度 0完整代码还算精简但它已经把命令模式的全部关键点都覆盖了。你把这段代码跑通再去看Spring里那些基于命令模式思想的实现或者Netty的ChannelHandler链思路会清晰很多。4. 常见问题与排查技巧实录4.1 撤销功能里的状态保存最容易翻车的地方我在实际项目里见过最典型的撤销实现错误是把“撤销”写成了“再次执行”。原因就是命令对象的undo方法里没有保存执行前的状态直接在undo里调用了接收者的某个反向方法一旦业务逻辑有多个分支撤销就会出乱子。比如刚才的风扇有人可能会这么写undoOverride public void undo() { fan.off(); // 错误示范 }这种写法只在“命令是从off状态来的”情况下成立。如果执行FanHighCommand之前风扇本来就是low撤销时直接off状态就错了。正确做法一定是在execute时先把前一个状态存下来程序员要记住撤销的核心是“恢复执行前”不是“变为相反的”。如果接收者有多个互斥状态比如灯的开/关、风扇的off/low/high请务必在execute方法里先记录prevState然后在undo里用setPrevState恢复。这种方式虽然多写几行代码但逻辑可靠得多。4.2 空命令与异常处理几个隐蔽的坑第一个坑插槽没有绑定命令时直接调用会抛空指针。解决办法就是我在第3节里提到的NoCommand空对象。很多框架源码里都有这种类别觉得它多余它能帮你省掉无数个if (command ! null)判断。第二个坑命令对象生命周期过长。如果你的命令对象被放到队列或历史栈中它持有的接收者引用也会一直存活。如果在Web应用里用命令模式做异步任务接收者本身是有状态且重量级的对象小心内存泄漏。这时候接收者应该设计得足够轻或者命令对象在执行完后主动释放接收者引用。第三个坑execute方法内部如果抛了异常undo栈要不要记录这没有唯一正确答案。我个人的经验是如果execute没有完成状态变更就不应该入栈如果执行到一半抛异常最好先保证接收者状态回滚到执行前再决定是否入栈。简单起见可以在execute里用try-catch包住业务逻辑状态没变更成功就不push到undo栈。4.3 与策略模式、观察者模式的辨析面试高频题之一命令模式和策略模式有什么区别我给一个很直白的判断标准策略模式关注“怎么做”命令模式关注“做什么”。策略模式里Context持有策略对象运行时替换算法命令模式里Invoker持有命令对象触发执行并且命令对象可以保存、排队、撤销。你看Runnable接口它更像命令模式因为任务被封装起来延迟执行而Comparator它显然是策略模式因为排序算法可以替换。观察者模式则通常理解为“发布-订阅”主题状态变化时通知观察者观察者的update方法由主题统一触发。命令模式更主动调用者决定什么时候、以什么方式触发命令。两者本质上都实现了发布方与接收方的解耦但观察者模式的通知逻辑是主题内部的命令模式的动作触发则是外部注入的。理解到这一层你在系统设计里就不会用错。5. 命令模式在真实项目里的典型应用与扩展5.1 事务与日志回滚从演示到企业级实践很多人以为命令模式只是教学玩具但其实它是很多企业级框架的底层思想。比如数据库事务你可以把每条SQL操作封装成一个命令对象执行时记录日志回滚时逆向执行undo。Java里最典型的例子是Swing的Action和UndoManager以及Spring的事务模板里对回滚的处理方式。再举一个我参与过的真实业务场景一个配置中心管理员批量修改设备配置。每一条修改都是一条命令把这些命令按顺序执行同时持久化到一张命令日志表。如果某一条命令执行失败系统自动把前面已经执行的命令全部undo一遍从而保证批量操作的原子性。这种设计用if-else逐条处理会很难维护但用命令模式天然就是“命令集合 日志 顺序回滚”的组合代码结构清晰得让人舒服。如果你想把命令模式用于日志系统可以给命令接口增加一个store()或load()方法支持把命令序列化保存到文件或数据库。Java的序列化机制或者JSON序列化都能派上用场。这样系统重启后还能恢复上次未完成的命令队列这就是“持久化命令”的概念。5.2 宏命令与组合使用命令的分层艺术宏命令就是用一个命令对象封装一组子命令执行宏命令时按顺序执行所有子命令。这有点像宏录制你按下“录制”键后续操作都被封装成命令对象收集起来按下“播放”键依次执行宏内所有命令。实现宏命令特别简单就是组合模式与命令模式的结合package command; import java.util.ArrayList; import java.util.List; public class MacroCommand implements Command { private ListCommand commands new ArrayList(); public void addCommand(Command command) { commands.add(command); } Override public void execute() { for (Command command : commands) { command.execute(); } } Override public void undo() { // 逆序撤销 for (int i commands.size() - 1; i 0; i--) { commands.get(i).undo(); } } }注意撤销顺序必须逆序比如宏命令是“开灯开风扇”撤销时应该先关风扇再关灯否则结果和预期不一致。这个细节我在接手别人代码时发现过好几次十有八九都是正序撤销然后状态全乱。宏命令的价值在于把多个命令聚合成一个语义化命令。比如UI里的“一键回家”按钮点击后执行关灯、关空调、开摄像头、锁门四条命令你只需要把它封装成一个MacroCommand按钮绑定它即可。以后要调整流程改宏命令内部组合就行按钮代码完全不用动。5.3 队列与线程池中的命令模式因为命令对象封装了“动作接收者”天然适合扔到队列里由线程池异步执行。我做过一个文件批量转换工具每个文件转换任务就是一个命令对象包含输入路径、输出路径、转换器接收者。把任务提交给线程池主线程不用等待还能统一控制队列长度和失败重试。这里有个关键点命令对象必须是可序列化的至少不可变否则多线程环境下易燃易爆。我的经验是命令对象的字段都用final修饰接收者尽量无状态或者接收者本身就是线程安全的服务类。否则就算命令模式思想再优雅多线程下照样翻车。6. 进阶心得与实际项目决策建议6.1 写在最后什么时候该用什么时候别用我个人在使用命令模式时有一条判断标准如果这段业务代码只被调用一次也没有保存、排队、撤销的需求那就没有必要硬套命令模式。设计模式不是勋章堆得越多越高级它能解决问题才算有价值。命令模式最适用的场景是需要把“动作”作为一等公民来处理比如撤销、事务、队列、宏命令。聊聊我在实际项目里的一个反面教训。之前有个同事在一个非常简单的查询接口里套了命令模式一个查询流程拆出了六个类QueryCommand、QueryReceiver、QueryInvoker……本来二十行的业务逻辑硬生生膨胀成了二十个文件后来维护的人查代码查得怀疑人生。设计模式的正确姿态是“按需引入”先写简洁直接的代码等出现重复的调用逻辑、撤销需求、队列需求时再逐步重构到命令模式。不要为了用模式而用模式这一点我踩过坑希望你能直接避开。6.2 给新手的练习路径建议如果你想把命令模式牢固掌握我建议按这个顺序去练先照着本文代码跑通遥控器项目理解四个角色的关系。给项目增加一个“电视”接收者实现电视的开、关、切换频道命令练习新增代码不修改已有类。自测撤销功能开灯 - 关灯 - 撤销看状态是否正确风扇先开高速再开低速再撤销看是否恢复到高速而不是停止。自己封装一个宏命令把“回家模式”和“离家模式”各做成一条宏命令。最后把命令模式用到你自己的小项目里比如做一个简单的文本编辑器封装“插入文字”“删除文字”两个命令实现CtrlZ撤销。练完这五步你对命令模式的理解会和只看概念完全不同。代码这种东西不动手永远是纸面知识。最后分享一个小技巧在跑这些练习的时候给每个命令类加一个toString方法把接收者名称和动作类型打印出来方便调试时一眼看出当前按的到底是哪条命令。别小看这个调试习惯我之前在排查撤销顺序问题时就是靠日志里打印的命令顺序定位到正序撤销的bug的。命令模式是一个入门门槛低但进阶空间大的模式它连接着面向对象设计的很多核心思想封装变化、单一职责、开闭原则。把这一篇里的代码吃透再去看Spring的事务管理、Java的Runnable机制、以及各种UI框架的Action体系你会觉得很多地方都似曾相识。
