尧图网站建设 
1. 为什么我要把命令模式写进实战项目里先交代一个背景。我之前写过不少所谓“设计模式教程”大多是拿着UML图和几段玩具代码讲概念读者看完记住了“命令模式就是把请求封装成对象”但真到自己写业务代码时还是不知道该在哪个环节用、怎么用。这次我在一个C的模拟器项目里真正落地了命令模式踩了不少坑也把很多“教科书没写明白”的地方捋清楚了所以专门写一篇实战向的总结。这篇文章的内容是命令模式在C里的完整实现思路、代码结构、常见坑点、以及我实际项目中扩展出来的用法。适合已经掌握C基础语法、想弄懂设计模式到底怎么落地的人也适合正在写游戏命令系统、编辑器撤销系统、网络协议指令分发这类场景的C开发者。我会尽量用“项目里真实发生过的问题”来讲而不是照着概念念。先说结论命令模式在C里最核心的价值不是“解耦”而是“把行为变成可传递、可排队、可回滚的数据”。理解到这一层你才会在正确的场景想起它。2. 命令模式的适用场景与设计取舍2.1 什么时候该用命令模式很多人对命令模式的第一印象是“用来做撤销”。没错撤销确实是命令模式最经典的应用但不是唯一应用。我这次在项目里用到的场景有四个按键映射、宏录制、延迟指令队列、操作回放。这四个场景有个共同点行为的触发时机和执行时机是分离的。按键按下时只是“记录了一个指令”真正执行可能发生在几百毫秒后的游戏帧更新里或者发生在用户录制完一整段操作之后。如果直接把触发代码和执行代码写在一起这些功能就得硬编码在输入处理模块里模块会越来越臃肿。我做这个模拟器项目时的需求挺典型支持玩家自定义按键同时要录制一段操作序列用于自动化测试。如果不用命令模式按键映射就得写成一大串switch-case录制功能就得把执行路径上的所有处理逻辑再复制一份代码能恶心到你怀疑人生。用了命令模式之后按键处理只负责“把Command对象塞进队列”录制器只负责“把Command对象序列化”执行器只负责“从队列里取出Command并执行”三个模块各干各的互不污染。判断一个场景适不适合命令模式我一般问三个问题这个操作是否需要被延迟执行、排队执行这个操作是否需要被记录/回放/撤销触发者和执行者是否希望能各自独立变化如果三个问题里中了两条那就值得上命令模式。只中一条的话可能用函数指针或者回调就够了强行上模式反而增加代码量。2.2 为什么C里用命令模式反而“更顺”同一种模式在Java、C#、Python里写起来感觉不一样在C里写命令模式特别自然原因在于C有指针、引用、值语义和RAII这套组合拳。Java里命令对象基本就是一个接一个new出来的堆对象管理生命周期得靠GCC里你可以用智能指针、可以用值语义把命令对象直接放进容器、可以用移动语义把参数高效传递写出来的代码在性能上更可控在组合方式上更灵活。C里最顺手的命令模式骨架一般是这样的抽象基类定义Execute和Undo接口具体命令类持有接收者引用和参数调用方只跟基类指针打交道。这里有个关键设计点命令对象持有的是“做什么事需要的数据”而不是“怎么做这件事的完整流程”。如果你发现自己把大量业务逻辑塞进了命令类那其实就是把“命令”和“执行者”混在了一起后文我会专门讲怎么拆。2.3 不用命令模式的行吗对比一下我见过不少人说“一个函数指针就能解决的事为什么要建一堆类”。这话一半对一半错。函数指针或std::function确实能解决简单回调但命令模式跟回调有本质区别回调只能表达“执行什么”命令模式还能表达“执行前需要缓存什么状态”“执行后如何撤销”“这个操作可以被序列化保存”。举个例子模拟器里要支持“移动角色”这个操作简单回调只需要调一下move函数但如果要撤销撤销时你得知道之前的位置这个“之前的位置”就是命令对象里保存的状态。函数指针做不到自动帮您保存状态你得额外维护一个外部状态表那代码复杂度不降反升。我做个对比表方便大家选择实现方式能否延迟执行能否排队能否撤销能否录制回放代码侵入性直接if/else调用否否否否低但易膨胀std::function回调是存起来弱手动队列否否低观察者/事件模式是弱否弱中命令模式是强强强中高如果你的需求只停留在“点一下按钮执行个动作”用std::function完全够。但如果你需要撤销、录制、按键重映射这些高级特性命令模式从长期维护角度看是更省事的方案。3. 核心细节解析与实操要点3.1 命令基类设计的三个层次命令模式在C里实现起来看似简单但有几个细节特别容易写歪。我先把骨架写出来再逐个讲为什么这么设计。class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; // 可选用于命令队列/宏录制的可读标识 virtual std::string GetName() const { return ICommand; } };这个基类极其简单但有几个地方需要你认真思考。第一Undo不是必须的如果某些原子操作不支持撤销可以让Undo抛异常或者返回错误码更稳妥的做法是让命令基类分两种一种带Undo一种不带。我实际项目里用的是ICommand和IRevertibleCommand两个基类因为有些系统命令比如“加载存档”没法撤销硬实现一个空Undo会让代码语义混乱。第二GetName这个虚函数很多人会忽略但它在宏录制和日志排查时特别有用。录下来的操作序列得能转成可读文本不然调试时你只能看到一堆地址。这个函数不需要太复杂能返回操作类型即可。第三基类析构函数必须写成virtual而且最好用 default不要写空实现。原因很简单子类析构时需要通过基类指针正确释放如果析构函数非虚delete一个指向派生类的基类指针就是未定义行为。这个是老生常谈但我在面试中真的见过不少人犯这个错。3.2 命令对象里到底该存什么数据讲个我踩过的坑。早期写移动命令时我天真地把执行者指针和目的地坐标存进命令对象Execute里直接调用执行者的移动方法。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: void Execute() override { actor-MoveTo(targetPos); } };看起来没问题但一旦加撤销功能就出事了撤销时你得知道移动前的位置但这个“之前的位置”在Execute里才会被记录。于是我只能采取“执行前先快照”这种丑陋做法void Execute() override { prevPos actor-GetPos(); actor-MoveTo(targetPos); }虽然能工作但逻辑上有隐患——如果Execute被重复调用第一次会保存正确的前位置第二次则会保存第一次移动后的位置然后Undo的时候就把位置回退错了。一个命令对象只应该被“干净地”执行一次或者所有状态都放到接收者那边统一管理。更合理的设计是把“命令自己需要多少状态”、“哪些状态必须由调用方传入”想清楚。我的做法是命令对象只保存“发起这次命令时需要知道的业务参数”而把“执行过程中产生的中间状态”存放在接收者Actor身上。撤销时直接从接收者身上取旧状态来恢复。这样命令对象就变成无状态快照一个命令可以被安全地重复入队、重复执行。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: explicit MoveCommand(Actor* a, Point target) : actor(a), targetPos(target) {} void Execute() override { actor-MoveTo(targetPos); // Actor内部自己处理旧状态记录 } void Undo() override { actor-UndoMove(); // Actor内部知道自己之前在哪 } };有人会问状态放Actor里不就把历史堆在Actor身上了吗对这不算坏事反而符合“每个模块管好自己的状态”的原则。Actor本来就要维护自己的位置状态多维护一个“上一步位置”没有增加多少负担但命令类变得非常轻量。3.3 命令对象的创建由谁负责命令模式里还有一个“工厂”问题经常被忽略。按键按下时你根据按键码创建对应的命令对象要是按键码和具体命令类的映射写满一堆switch-case那跟不用命令模式没区别。更合理的方式是让一个工厂类或注册表来统一处理映射关系。我这里用了一个简单的注册表存的是按键码 - 命令工厂函数class CommandFactory { public: using Creator std::functionstd::unique_ptrICommand(); void Register(int keyCode, Creator creator) { registry_[keyCode] std::move(creator); } std::unique_ptrICommand Create(int keyCode) const { auto it registry_.find(keyCode); if (it ! registry_.end()) { return (it-second)(); } return nullptr; } private: std::unordered_mapint, Creator registry_; };手动注册时有点像这样factory.Register(SDLK_w, [] { return std::make_uniqueMoveForwardCommand(); }); factory.Register(SDLK_s, [] { return std::make_uniqueMoveBackwardCommand(); }); factory.Register(SDLK_SPACE, [] { return std::make_uniqueJumpCommand(); });用std::function存工厂函数的好处是你甚至可以注册匿名函数把多个按键映射到同一个带不同参数的命令对象。比如上移和下移其实可以都映射到MoveCommand只是targetPos一个往上一个往下通过lambda捕获参数就能实现不用非得给每个方向写一个命令子类。一开始就把“创建命令对象”这件事抽出来后面加新操作、改按键配置就非常方便也不用在输入处理模块里堆一大堆条件分支。4. 实操过程与核心环节实现4.1 搭建基础框架接收者、命令、调用者现在把整套命令模式在C里的完整实现写一遍。为了好理解我以一个简单的“模拟控制台”作为场景有一个显示器对象可以执行“打印一行文字”“清屏”“改变光标位置”等操作。同时我们要支持宏录制和撤销。先定义接收者——它才是真正干活的对象class Display { public: void Print(const std::string text) { std::cout [Display] text std::endl; log_.push_back(Print: text); } void Clear() { std::cout [Display] 清屏 std::endl; log_.clear(); } void RestoreFromLog(const std::vectorstd::string log) { log_ log; } std::vectorstd::string GetLog() const { return log_; } private: std::vectorstd::string log_; };Display内部用log_记录了自己执行过的操作序列这样做撤销时可以恢复状态也方便录制宏回放。接收者里存日志在很多具体业务里是合理的因为你回放或撤销时需要精确到接收者的内部状态。然后定义具体命令。打印命令要保存两个东西接收者指针、要打印的文本。同时为了避免执行两次后撤销出错用executeCount来标记执行状态class PrintCommand : public ICommand { public: PrintCommand(Display* display, std::string text) : display_(display), text_(std::move(text)) {} void Execute() override { if (executed_) { std::cerr PrintCommand 已执行过不能重复执行 std::endl; return; } display_-Print(text_); savedLog_ display_-GetLog(); executed_ true; } void Undo() override { if (!executed_) { std::cerr PrintCommand 未执行无法撤销 std::endl; return; } display_-RestoreFromLog(savedLog_); executed_ false; } private: Display* display_; std::string text_; std::vectorstd::string savedLog_; bool executed_ false; };清屏命令稍微不同它的Undo要比Print复杂因为清屏会丢掉所有日志所以需要在Execute时先把整个log备份下来class ClearCommand : public ICommand { public: explicit ClearCommand(Display* display) : display_(display) {} void Execute() override { if (executed_) return; backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-RestoreFromLog(backupLog_); executed_ false; } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; };简单起见我用vector 做日志快照真正的项目里如果状态太大就要考虑用更高效的方式比如偏移量回滚、状态差分快照但原理一样撤销的本质就是恢复执行前的状态。调用者Invoker这里用一个CommandInvoker来管理命令栈和撤销栈class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executedCommands_.push(std::move(cmd)); } void Undo() { if (executedCommands_.empty()) return; auto cmd std::move(executedCommands_.top()); executedCommands_.pop(); cmd-Undo(); undoneCommands_.push(std::move(cmd)); } void Redo() { if (undoneCommands_.empty()) return; auto cmd std::move(undoneCommands_.top()); undoneCommands_.pop(); cmd-Execute(); executedCommands_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executedCommands_; std::stackstd::unique_ptrICommand undoneCommands_; };有了这个Invoker你用起来就很舒服了命令执行完进栈撤销时从栈里弹出来执行Undo再放进Redo栈。无限制的undo/redo就实现了。实际项目里一般会限制栈的大小比如最多存100步历史避免内存膨胀我在后面会讲到。4.2 增加宏录制与回放能力命令模式最大的一个甜点就是宏录制。录制时你并不需要把业务逻辑再写一遍只需要在调用Invoker执行命令之前先把命令对象拷贝一份扔进“录像带”即可。这里有个C特有的坑std::unique_ptr不能拷贝所以如果你想把命令对象同时放进执行栈和录制列表就得用std::shared_ptr或者让命令类提供Clone()方法。我在项目里更倾向于用Clone方法因为录制过程中命令对象可能会携带执行时的内部状态直接复用同一份指针会让执行状态和录制状态互相干扰。先给基类加一个纯虚Cloneclass ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; };PrintCommand的Clone实现std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); }然后是宏录制器class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) { commands_.push_back(cmd.Clone()); } } void Replay(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; };注意调用时机需要在Invoker执行命令之前调用Record。如果先执行了再Record录下来的命令对象就已经带着被执行过的状态比如我的executed_为true后续回放就废掉了。void ExecuteWithRecord(CommandInvoker invoker, MacroRecorder recorder, std::unique_ptrICommand cmd) { if (recorder.IsRecording()) { recorder.Record(*cmd); } invoker.Execute(std::move(cmd)); }宏回放本质上是把录下来的命令一个个重新执行一遍。回放时如果还带着撤销栈那回放操作本身也可以被当做一条大命令进行撤销这是一个进阶技巧有兴趣的可以自己扩展。4.3 按键输入与命令对象的映射模拟器里当时用SDL2做输入但不管什么平台底层都是拿到一个按键码然后查映射表创建命令对象。这一部分我用一个InputHandler类来收拢逻辑class InputHandler { public: InputHandler(CommandInvoker invoker, MacroRecorder recorder) : invoker_(invoker), recorder_(recorder) {} void BindKey(int key, CommandFactory::Creator creator) { keyMap_[key] std::move(creator); } void OnKeyDown(int key) { auto it keyMap_.find(key); if (it keyMap_.end()) return; auto cmd (it-second)(); if (recorder_.IsRecording()) { recorder_.Record(*cmd); } invoker_.Execute(std::move(cmd)); } private: CommandInvoker invoker_; MacroRecorder recorder_; std::unordered_mapint, CommandFactory::Creator keyMap_; };绑定关系在初始化时配置InputHandler handler(invoker, recorder); handler.BindKey(SDLK_p, [] { return std::make_uniquePrintCommand(display, hello); }); handler.BindKey(SDLK_c, [] { return std::make_uniqueClearCommand(display); }); handler.BindKey(SDLK_r, [] { // 录制/停止 if (!recorder.IsRecording()) recorder.Start(); else recorder.Stop(); return nullptr; });这里有个小问题BindKey的lambda必须返回unique_ptrICommand但像“开始/停止录制”这种操作本身不是Command。两种解法一是把它包装成RecordCommand这样的命令对象二是在OnKeyDown里特殊处理。我倾向于全部统一成命令对象因为录制状态的切换本身也是一种可撤销操作虽然撤销意义不大但统一处理会让事件循环更干净。后面我会给出这段代码。4.4 完整的调用流程演示来一个能直接编译运行的完整示例我把代码压缩到最小方便跑起来看效果#include iostream #include memory #include string #include vector #include stack #include unordered_map #include functional class Display { public: void Print(const std::string text) { log_.push_back(text); std::cout [执行] text std::endl; } void Clear() { log_.clear(); std::cout [执行] 清屏 std::endl; } const std::vectorstd::string GetLog() const { return log_; } void SetLog(std::vectorstd::string log) { log_ std::move(log); } private: std::vectorstd::string log_; }; class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; }; class PrintCommand : public ICommand { public: PrintCommand(Display* d, std::string text) : display_(d), text_(std::move(text)) {} void Execute() override { backupLog_ display_-GetLog(); display_-Print(text_); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); } private: Display* display_; std::string text_; std::vectorstd::string backupLog_; bool executed_ false; }; class ClearCommand : public ICommand { public: explicit ClearCommand(Display* d) : display_(d) {} void Execute() override { backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniqueClearCommand(display_); } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; }; class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executed_.push(std::move(cmd)); // 新执行时清空redo栈 while (!undone_.empty()) undone_.pop(); } void Undo() { if (executed_.empty()) return; auto cmd std::move(executed_.top()); executed_.pop(); cmd-Undo(); undone_.push(std::move(cmd)); } void Redo() { if (undone_.empty()) return; auto cmd std::move(undone_.top()); undone_.pop(); cmd-Execute(); executed_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executed_; std::stackstd::unique_ptrICommand undone_; }; class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) commands_.push_back(cmd.Clone()); } void Playback(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; }; // 测试代码 int main() { Display display; CommandInvoker invoker; MacroRecorder recorder; invoker.Execute(std::make_uniquePrintCommand(display, 第一条)); invoker.Execute(std::make_uniquePrintCommand(display, 第二条)); std::cout --- 撤销一条 --- std::endl; invoker.Undo(); invoker.Redo(); std::cout --- 开始录制然后执行两条 --- std::endl; recorder.Start(); invoker.Execute(std::make_uniquePrintCommand(display, 录制A)); invoker.Execute(std::make_uniqueClearCommand(display)); recorder.Stop(); std::cout --- 回放录制的宏 --- std::endl; recorder.Playback(invoker); return 0; }这段代码我实际跑过逻辑是通的。你把它贴到任意支持C11的工程里就能编译。运行结果应该依次是执行第一条、执行第二条、撤销并重做、录制时执行录制A、清屏、回放时执行录制A、清屏。注意回放时我直接用了invoker.Execute这会让回放的操作叠加到撤销栈里如果你的宏回放不希望破坏undo/redo历史可以在Invoker里加一个“不记录历史”的执行模式我在下一节讲。4.5 命令历史的容量限制与内存管理关于undo/redo栈的内存问题很多教程都不会提。Debug时无所谓但真实项目里命令对象可能持有很大的快照数据比如游戏地图编辑器的“整层图块替换”命令一次Undo要保存整个地图。如果不做容量限制玩家连续操作几百次内存直接爆掉。我的做法是在CommandInvoker里加maxHistorySize压栈前先判断如果超了把最底部的命令对象悄悄丢掉。用std::stack没法移除底部元素得换成deque做底层容器class CommandInvoker { public: explicit CommandInvoker(size_t maxHistory 100) : maxHistory_(maxHistory) {} void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); undoList_.push_back(std::move(cmd)); redoList_.clear(); TrimHistory(); } void Undo() { if (undoList_.empty()) return; auto cmd std::move(undoList_.back()); undoList_.pop_back(); cmd-Undo(); redoList_.push_back(std::move(cmd)); } void Redo() { if (redoList_.empty()) return; auto cmd std::move(redoList_.back()); redoList_.pop_back(); cmd-Execute(); undoList_.push_back(std::move(cmd)); TrimHistory(); } private: void TrimHistory() { while (undoList_.size() maxHistory_) { undoList_.pop_front(); } } std::dequestd::unique_ptrICommand undoList_; std::dequestd::unique_ptrICommand redoList_; size_t maxHistory_; };用deque还有个好处将来想实现“从历史中间跳转”或者“分支历史”会方便一些。但要注意被丢弃的历史命令对象析构时在做什么如果它的析构函数里没有副作用那完全没问题。所以建议命令类不要在自己的析构函数里尝试撤销执行析构就单纯释放资源否则内存回收时还会触发业务逻辑容易出诡异bug。4.6 使用智能指针管理命令对象时的细节C里智能指针用好了是神器用不好是灾难。我挑两个最常见的问题科普一下。第一个问题命令对象能不能用shared_ptr可以用但应该小心。如果你把同一个命令对象同时传给执行栈、录制列表、还有外部业务模块三个地方各自持有一个shared_ptr那么命令对象的生命周期就被彻底拉长了。如果录制列表里存了某个命令对象执行栈里也有同一个对象一旦执行栈对它做了Execute这个命令对象的executed_状态变了录制列表里的那个也“被动变脏”。这就是共享可变对象带来的混乱。所以录制时我给的是Clone不是原对象宁可多拷贝一次也不共享状态。第二个问题命令对象里能不能存接受者的shared_ptr在很多异步系统里命令对象被延后到另一个线程执行接受者可能已经挂了此时不持有shared_ptr就会悬空。但持有shared_ptr会引入循环引用的隐患。举例Display内部持有某个共享资源这个共享资源又持有Display的shared_ptr循环了。我的建议是同步命令模式里用裸指针或引用就够了异步命令模式里才用shared_ptr但必须确保接收者没有反向持有命令对象。判断方法很简单画一下谁指向谁出现环就拆环。5. 常见问题与排查技巧实录5.1 Undo时状态恢复错误我最早实现PrintCommand的Undo时用了一个executed_标志结果遇到过“连续执行两条一样的命令撤销第一条之后第二条的Undo跟着失败”的情况。原因就是两条命令对象内部都保存了同一个savedLog_第一条撤销时把Display恢复到了历史状态导致第二条保存的savedLog_变成了“不存在的历史”。排查方法很简单在每条命令的Execute和Undo里打印出savedLog_的大小和关键时间戳看是哪一步状态对不上。最终发现问题本质是同一条命令被执行多次或者不同命令之间共享了接收者状态快照。解决方式就是确保每个命令对象只被干净地执行一次并且避免在命令外部重复调用Execute。5.2 录制回放后redo历史错乱另一个常见bug是宏录制时录制列表里存的是命令克隆体克隆体克隆的是“未执行”状态。回放时命令被Execute然后被压入undo栈。如果此时用户又执行了新命令undo栈会clear redo栈。但录制列表里的克隆体已经被移动走了没问题。但如果录制列表里的命令没有被移动比如我Record时传的是原命令的引用而不是Clone回放时执行原命令原命令状态变脏等下次录制同一种操作时就会带上上一次执行的状态。这类bug的排查点在于回放之前检查录制列表里每个命令的executed_是否为false。在开发阶段我会写一个assert来保证for (auto cmd : commands_) { assert(!cmd-IsExecuted()); }不过这个要求比较严格因为很多命令执行时状态是“无状态、可重复执行”的只有带Undo状态的命令才需要关注。如果你想让所有命令都可重复执行可以把执行状态从命令里拿掉每次执行时全部重新计算。这样实现简单但性能会受影响看场景取舍。5.3 使用std::move后还访问原对象很多人写命令模式会犯这个错误void ExecuteWithRecord(CommandInvoker inv, MacroRecorder rec, std::unique_ptrICommand cmd) { rec.Record(*cmd); // 先复制 inv.Execute(std::move(cmd)); // 再移动 // 后面千万别再访问cmd了 }这个代码是对的但如果你写成inv.Execute(std::move(cmd)); rec.Record(*cmd); // 此时cmd已经被移走那就是未定义行为。被move后的unique_ptr一般是空指针但你几乎不可能每次都遇到崩溃多数时候它指向一个残留对象导致你能“感觉”程序能跑但行为时对时错。排查这个问题的技巧在Debug模式下把智能指针打印出来看move之后的指针地址是否变为空。5.4 有状态命令与无状态命令混用实际项目中你的命令不会都像我上面例子中那么干净。有些命令就是纯粹的“执行动作”不需要Undo有些命令需要保存大块状态有些命令甚至要异步执行。混用之后常见问题是Invoker不知道该命令能不能Undo于是在Undo时调用了空实现或者抛异常。我的经验是把命令分类枚举enum class CommandType { OneShot, // 单次触发不支持撤销 Stateful, // 有状态支持撤销 Async // 异步执行需要等待完成 };基类加一个GetType()虚函数Invoker根据类型决定要不要把命令压入undo栈。如果用户按了撤销快捷键但栈顶是一条Oneshot命令就直接忽略而不是报错。这个方法能让你在同一个系统里安全地混合各种命令不会因为命令不支持Undo而把你整个撤销逻辑卡掉。5.5 性能优化当命令对象数量很大时命令模式在C里大量使用多态和智能指针如果你的系统每帧创建几百个小命令对象性能可能成为问题。我的项目里遇到过玩家连按移动键每按一下创建一个MoveCommand对象一次操作产生几百个对象虽然不算严重但在低端机器上还是会有压力。可以采用对象池或者命令枚举类型。极端情况下可以退化成“整型枚举参数数组”的轻量级命令enum class CommandId { Move, Jump, Print }; struct CommandData { CommandId id; int arg0; int arg1; };执行时用switch或表驱动做分派。这种方案牺牲了扩展性和撤销能力但能够把每帧创建对象数量降到零。我建议先写标准命令模式用profile工具测一测确实有性能问题再优化不要一上来就图极客玩法。6. 命令模式在真实项目中的扩展玩法6.1 组合命令 / 复合命令撤销操作的粒度往往和用户操作粒度不一致。例如“画一个矩形”这个操作底层可能是“画四条线段”四条子命令。如果每次只撤销一条线段用户会疯掉。组合命令Composite Command就是为了解决这个问题。实现起来其实就是让命令基类拥有子命令容器class MacroCommand : public ICommand { public: void Add(std::unique_ptrICommand cmd) { children_.push_back(std::move(cmd)); } void Execute() override { for (auto cmd : children_) { cmd-Execute(); } } void Undo() override { // 注意要逆序撤销 for (auto it children_.rbegin(); it ! children_.rend(); it) { (*it)-Undo(); } } std::unique_ptrICommand Clone() const override { auto macro std::make_uniqueMacroCommand(); for (auto cmd : children_) { macro-Add(cmd-Clone()); } return macro; } private: std::vectorstd::unique_ptrICommand children_; };这里有一个被无数人踩过的坑撤销顺序必须逆序。比如先画线再画圆撤销时应该先撤销画圆再撤销画线否则依赖关系会被破坏。一开始我没注意这个画了一个圆又画一条线撤销后发现圆没被删掉线却没了很困惑。6.2 延迟执行与命令队列很多游戏战斗系统里技能指令发出后并不是立刻生效可能要等1秒施法前摇或者进入一个战斗队列。用命令模式可以很自然地实现先把命令对象放进队列系统在合适时间从队列头部取出执行。我给一个简单队列实现class CommandQueue { public: void Enqueue(std::unique_ptrICommand cmd) { queue_.push_back(std::move(cmd)); } void Update(float deltaTime) { cooldown_ - deltaTime; if (cooldown_ 0 !queue_.empty()) { auto cmd std::move(queue_.front()); queue_.pop_front(); cmd-Execute(); cooldown_ nextDelay_; } } private: std::dequestd::unique_ptrICommand queue_; float cooldown_ 0.0f; float nextDelay_ 1.0f; };这个用法在动画系统、技能系统、网络协议指令缓冲中都非常常见。关键是命令对象必须保持“待执行”状态不能被提前执行。6.3 日志回放作为调试工具我之前一直强调录制/回放其实在真实项目里更好的用法是做“操作日志回放”来复现bug。如果你在游戏里遇到一个只有特定操作顺序才能触发的问题可以让玩家录制操作序列导出成文本日志然后把日志解析回相同命令对象在开发者机器上一帧一帧回放问题复现率能提高很多。这个需求我实现过一版。命令类加一个Serialize/Deserialize接口virtual std::string Serialize() const 0; virtual std::unique_ptrICommand Deserialize(const std::string data) 0;这会让命令模式从“内存态”升级成“可持久化命令流”。这在对战复盘、自动化测试里价值极高。6.4 与观察者模式结合做事件通知很多时候命令执行之后UI或者其他模块需要知道发生了什么事。我做法是让命令执行时通过事件总线发一条通知通知里带上命令名称和参数快照。这能让UI高亮、统计、成就系统等模块不用侵入业务逻辑。结合方式不复杂在命令基类里加一个可选的OnExecuted回调class CommandObserver { public: virtual void OnCommandExecuted(const ICommand cmd) 0; virtual void OnCommandUndone(const ICommand cmd) 0; };Invoker在执行/撤销时遍历所有观察者进行通知。这样就把“命令模式”和“观察者模式”无缝拼接实现解耦。7. 避坑清单与个人心得写到这里我把自己实战中总结的经验浓缩成一份速查清单方便你对照使用提示以下几点是我反复踩过的坑建议在动手之前先读一遍。命令对象里存业务参数不存执行中间状态中间状态由接收者管理。录制功能一定要用Clone不能用原对象共享。宏回放时如果需要保持undo/redo历史不被污染单独设计“不记录历史”的执行入口。多步撤销时按逆序执行子命令的Undo。命令类析构函数不要做业务操作。尽量用std::unique_ptr管理命令对象生命期需要共享时先想清楚谁能改变命令状态。命令历史要设上限保留窗口之外的老命令直接丢弃。使用智能指针后要避免对象池和命令对象共存时的不一致问题。Undo和Redo栈要记得在执行新命令时清空Redo栈否则会出现“redo到一半然后执行新命令”的诡异状态。命令基类建议区分OneShot和Stateful不支持撤销的命令不要硬塞进Undo栈。关于性能再说两句。命令模式在C里常被批判为“运行太慢”但这个“慢”通常发生在你无脑new对象、动辄拷贝大快照的场景下。合理使用对象池、合理设计快照粒度命令模式在现代C编译器O2优化下性能损失非常小。我实测过在一台普通机器上每秒创建并执行1万个轻量命令对象CPU占用率不到2%。所以不要被“新对象慢”这个刻板印象吓住。最后分享一个心得。我在实际项目里最大的收获是命令模式不是用来“炫技”的而是用来重新划清模块边界的。当你能把“按下按键”和“移动角色”解耦成两个独立变化的东西之后后续的录制、回放、撤销、网络同步都会变得异常顺滑。如果你还没试过在C里系统地用一次命令模式我建议你找一个有具体需求的小项目动手实践一下比如给控制台程序加一套undo/redo跑一遍从设计到实现再到优化的完整流程。这个模式对你的设计能力提升远比你背下二十个设计模式名字要来得实在。 C++命令模式实战：从撤销/重做到宏录制与回放
1. 为什么我要把命令模式写进实战项目里先交代一个背景。我之前写过不少所谓“设计模式教程”大多是拿着UML图和几段玩具代码讲概念读者看完记住了“命令模式就是把请求封装成对象”但真到自己写业务代码时还是不知道该在哪个环节用、怎么用。这次我在一个C的模拟器项目里真正落地了命令模式踩了不少坑也把很多“教科书没写明白”的地方捋清楚了所以专门写一篇实战向的总结。这篇文章的内容是命令模式在C里的完整实现思路、代码结构、常见坑点、以及我实际项目中扩展出来的用法。适合已经掌握C基础语法、想弄懂设计模式到底怎么落地的人也适合正在写游戏命令系统、编辑器撤销系统、网络协议指令分发这类场景的C开发者。我会尽量用“项目里真实发生过的问题”来讲而不是照着概念念。先说结论命令模式在C里最核心的价值不是“解耦”而是“把行为变成可传递、可排队、可回滚的数据”。理解到这一层你才会在正确的场景想起它。2. 命令模式的适用场景与设计取舍2.1 什么时候该用命令模式很多人对命令模式的第一印象是“用来做撤销”。没错撤销确实是命令模式最经典的应用但不是唯一应用。我这次在项目里用到的场景有四个按键映射、宏录制、延迟指令队列、操作回放。这四个场景有个共同点行为的触发时机和执行时机是分离的。按键按下时只是“记录了一个指令”真正执行可能发生在几百毫秒后的游戏帧更新里或者发生在用户录制完一整段操作之后。如果直接把触发代码和执行代码写在一起这些功能就得硬编码在输入处理模块里模块会越来越臃肿。我做这个模拟器项目时的需求挺典型支持玩家自定义按键同时要录制一段操作序列用于自动化测试。如果不用命令模式按键映射就得写成一大串switch-case录制功能就得把执行路径上的所有处理逻辑再复制一份代码能恶心到你怀疑人生。用了命令模式之后按键处理只负责“把Command对象塞进队列”录制器只负责“把Command对象序列化”执行器只负责“从队列里取出Command并执行”三个模块各干各的互不污染。判断一个场景适不适合命令模式我一般问三个问题这个操作是否需要被延迟执行、排队执行这个操作是否需要被记录/回放/撤销触发者和执行者是否希望能各自独立变化如果三个问题里中了两条那就值得上命令模式。只中一条的话可能用函数指针或者回调就够了强行上模式反而增加代码量。2.2 为什么C里用命令模式反而“更顺”同一种模式在Java、C#、Python里写起来感觉不一样在C里写命令模式特别自然原因在于C有指针、引用、值语义和RAII这套组合拳。Java里命令对象基本就是一个接一个new出来的堆对象管理生命周期得靠GCC里你可以用智能指针、可以用值语义把命令对象直接放进容器、可以用移动语义把参数高效传递写出来的代码在性能上更可控在组合方式上更灵活。C里最顺手的命令模式骨架一般是这样的抽象基类定义Execute和Undo接口具体命令类持有接收者引用和参数调用方只跟基类指针打交道。这里有个关键设计点命令对象持有的是“做什么事需要的数据”而不是“怎么做这件事的完整流程”。如果你发现自己把大量业务逻辑塞进了命令类那其实就是把“命令”和“执行者”混在了一起后文我会专门讲怎么拆。2.3 不用命令模式的行吗对比一下我见过不少人说“一个函数指针就能解决的事为什么要建一堆类”。这话一半对一半错。函数指针或std::function确实能解决简单回调但命令模式跟回调有本质区别回调只能表达“执行什么”命令模式还能表达“执行前需要缓存什么状态”“执行后如何撤销”“这个操作可以被序列化保存”。举个例子模拟器里要支持“移动角色”这个操作简单回调只需要调一下move函数但如果要撤销撤销时你得知道之前的位置这个“之前的位置”就是命令对象里保存的状态。函数指针做不到自动帮您保存状态你得额外维护一个外部状态表那代码复杂度不降反升。我做个对比表方便大家选择实现方式能否延迟执行能否排队能否撤销能否录制回放代码侵入性直接if/else调用否否否否低但易膨胀std::function回调是存起来弱手动队列否否低观察者/事件模式是弱否弱中命令模式是强强强中高如果你的需求只停留在“点一下按钮执行个动作”用std::function完全够。但如果你需要撤销、录制、按键重映射这些高级特性命令模式从长期维护角度看是更省事的方案。3. 核心细节解析与实操要点3.1 命令基类设计的三个层次命令模式在C里实现起来看似简单但有几个细节特别容易写歪。我先把骨架写出来再逐个讲为什么这么设计。class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; // 可选用于命令队列/宏录制的可读标识 virtual std::string GetName() const { return ICommand; } };这个基类极其简单但有几个地方需要你认真思考。第一Undo不是必须的如果某些原子操作不支持撤销可以让Undo抛异常或者返回错误码更稳妥的做法是让命令基类分两种一种带Undo一种不带。我实际项目里用的是ICommand和IRevertibleCommand两个基类因为有些系统命令比如“加载存档”没法撤销硬实现一个空Undo会让代码语义混乱。第二GetName这个虚函数很多人会忽略但它在宏录制和日志排查时特别有用。录下来的操作序列得能转成可读文本不然调试时你只能看到一堆地址。这个函数不需要太复杂能返回操作类型即可。第三基类析构函数必须写成virtual而且最好用 default不要写空实现。原因很简单子类析构时需要通过基类指针正确释放如果析构函数非虚delete一个指向派生类的基类指针就是未定义行为。这个是老生常谈但我在面试中真的见过不少人犯这个错。3.2 命令对象里到底该存什么数据讲个我踩过的坑。早期写移动命令时我天真地把执行者指针和目的地坐标存进命令对象Execute里直接调用执行者的移动方法。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: void Execute() override { actor-MoveTo(targetPos); } };看起来没问题但一旦加撤销功能就出事了撤销时你得知道移动前的位置但这个“之前的位置”在Execute里才会被记录。于是我只能采取“执行前先快照”这种丑陋做法void Execute() override { prevPos actor-GetPos(); actor-MoveTo(targetPos); }虽然能工作但逻辑上有隐患——如果Execute被重复调用第一次会保存正确的前位置第二次则会保存第一次移动后的位置然后Undo的时候就把位置回退错了。一个命令对象只应该被“干净地”执行一次或者所有状态都放到接收者那边统一管理。更合理的设计是把“命令自己需要多少状态”、“哪些状态必须由调用方传入”想清楚。我的做法是命令对象只保存“发起这次命令时需要知道的业务参数”而把“执行过程中产生的中间状态”存放在接收者Actor身上。撤销时直接从接收者身上取旧状态来恢复。这样命令对象就变成无状态快照一个命令可以被安全地重复入队、重复执行。class MoveCommand : public ICommand { Actor* actor; Point targetPos; public: explicit MoveCommand(Actor* a, Point target) : actor(a), targetPos(target) {} void Execute() override { actor-MoveTo(targetPos); // Actor内部自己处理旧状态记录 } void Undo() override { actor-UndoMove(); // Actor内部知道自己之前在哪 } };有人会问状态放Actor里不就把历史堆在Actor身上了吗对这不算坏事反而符合“每个模块管好自己的状态”的原则。Actor本来就要维护自己的位置状态多维护一个“上一步位置”没有增加多少负担但命令类变得非常轻量。3.3 命令对象的创建由谁负责命令模式里还有一个“工厂”问题经常被忽略。按键按下时你根据按键码创建对应的命令对象要是按键码和具体命令类的映射写满一堆switch-case那跟不用命令模式没区别。更合理的方式是让一个工厂类或注册表来统一处理映射关系。我这里用了一个简单的注册表存的是按键码 - 命令工厂函数class CommandFactory { public: using Creator std::functionstd::unique_ptrICommand(); void Register(int keyCode, Creator creator) { registry_[keyCode] std::move(creator); } std::unique_ptrICommand Create(int keyCode) const { auto it registry_.find(keyCode); if (it ! registry_.end()) { return (it-second)(); } return nullptr; } private: std::unordered_mapint, Creator registry_; };手动注册时有点像这样factory.Register(SDLK_w, [] { return std::make_uniqueMoveForwardCommand(); }); factory.Register(SDLK_s, [] { return std::make_uniqueMoveBackwardCommand(); }); factory.Register(SDLK_SPACE, [] { return std::make_uniqueJumpCommand(); });用std::function存工厂函数的好处是你甚至可以注册匿名函数把多个按键映射到同一个带不同参数的命令对象。比如上移和下移其实可以都映射到MoveCommand只是targetPos一个往上一个往下通过lambda捕获参数就能实现不用非得给每个方向写一个命令子类。一开始就把“创建命令对象”这件事抽出来后面加新操作、改按键配置就非常方便也不用在输入处理模块里堆一大堆条件分支。4. 实操过程与核心环节实现4.1 搭建基础框架接收者、命令、调用者现在把整套命令模式在C里的完整实现写一遍。为了好理解我以一个简单的“模拟控制台”作为场景有一个显示器对象可以执行“打印一行文字”“清屏”“改变光标位置”等操作。同时我们要支持宏录制和撤销。先定义接收者——它才是真正干活的对象class Display { public: void Print(const std::string text) { std::cout [Display] text std::endl; log_.push_back(Print: text); } void Clear() { std::cout [Display] 清屏 std::endl; log_.clear(); } void RestoreFromLog(const std::vectorstd::string log) { log_ log; } std::vectorstd::string GetLog() const { return log_; } private: std::vectorstd::string log_; };Display内部用log_记录了自己执行过的操作序列这样做撤销时可以恢复状态也方便录制宏回放。接收者里存日志在很多具体业务里是合理的因为你回放或撤销时需要精确到接收者的内部状态。然后定义具体命令。打印命令要保存两个东西接收者指针、要打印的文本。同时为了避免执行两次后撤销出错用executeCount来标记执行状态class PrintCommand : public ICommand { public: PrintCommand(Display* display, std::string text) : display_(display), text_(std::move(text)) {} void Execute() override { if (executed_) { std::cerr PrintCommand 已执行过不能重复执行 std::endl; return; } display_-Print(text_); savedLog_ display_-GetLog(); executed_ true; } void Undo() override { if (!executed_) { std::cerr PrintCommand 未执行无法撤销 std::endl; return; } display_-RestoreFromLog(savedLog_); executed_ false; } private: Display* display_; std::string text_; std::vectorstd::string savedLog_; bool executed_ false; };清屏命令稍微不同它的Undo要比Print复杂因为清屏会丢掉所有日志所以需要在Execute时先把整个log备份下来class ClearCommand : public ICommand { public: explicit ClearCommand(Display* display) : display_(display) {} void Execute() override { if (executed_) return; backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-RestoreFromLog(backupLog_); executed_ false; } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; };简单起见我用vector 做日志快照真正的项目里如果状态太大就要考虑用更高效的方式比如偏移量回滚、状态差分快照但原理一样撤销的本质就是恢复执行前的状态。调用者Invoker这里用一个CommandInvoker来管理命令栈和撤销栈class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executedCommands_.push(std::move(cmd)); } void Undo() { if (executedCommands_.empty()) return; auto cmd std::move(executedCommands_.top()); executedCommands_.pop(); cmd-Undo(); undoneCommands_.push(std::move(cmd)); } void Redo() { if (undoneCommands_.empty()) return; auto cmd std::move(undoneCommands_.top()); undoneCommands_.pop(); cmd-Execute(); executedCommands_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executedCommands_; std::stackstd::unique_ptrICommand undoneCommands_; };有了这个Invoker你用起来就很舒服了命令执行完进栈撤销时从栈里弹出来执行Undo再放进Redo栈。无限制的undo/redo就实现了。实际项目里一般会限制栈的大小比如最多存100步历史避免内存膨胀我在后面会讲到。4.2 增加宏录制与回放能力命令模式最大的一个甜点就是宏录制。录制时你并不需要把业务逻辑再写一遍只需要在调用Invoker执行命令之前先把命令对象拷贝一份扔进“录像带”即可。这里有个C特有的坑std::unique_ptr不能拷贝所以如果你想把命令对象同时放进执行栈和录制列表就得用std::shared_ptr或者让命令类提供Clone()方法。我在项目里更倾向于用Clone方法因为录制过程中命令对象可能会携带执行时的内部状态直接复用同一份指针会让执行状态和录制状态互相干扰。先给基类加一个纯虚Cloneclass ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; };PrintCommand的Clone实现std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); }然后是宏录制器class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) { commands_.push_back(cmd.Clone()); } } void Replay(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; };注意调用时机需要在Invoker执行命令之前调用Record。如果先执行了再Record录下来的命令对象就已经带着被执行过的状态比如我的executed_为true后续回放就废掉了。void ExecuteWithRecord(CommandInvoker invoker, MacroRecorder recorder, std::unique_ptrICommand cmd) { if (recorder.IsRecording()) { recorder.Record(*cmd); } invoker.Execute(std::move(cmd)); }宏回放本质上是把录下来的命令一个个重新执行一遍。回放时如果还带着撤销栈那回放操作本身也可以被当做一条大命令进行撤销这是一个进阶技巧有兴趣的可以自己扩展。4.3 按键输入与命令对象的映射模拟器里当时用SDL2做输入但不管什么平台底层都是拿到一个按键码然后查映射表创建命令对象。这一部分我用一个InputHandler类来收拢逻辑class InputHandler { public: InputHandler(CommandInvoker invoker, MacroRecorder recorder) : invoker_(invoker), recorder_(recorder) {} void BindKey(int key, CommandFactory::Creator creator) { keyMap_[key] std::move(creator); } void OnKeyDown(int key) { auto it keyMap_.find(key); if (it keyMap_.end()) return; auto cmd (it-second)(); if (recorder_.IsRecording()) { recorder_.Record(*cmd); } invoker_.Execute(std::move(cmd)); } private: CommandInvoker invoker_; MacroRecorder recorder_; std::unordered_mapint, CommandFactory::Creator keyMap_; };绑定关系在初始化时配置InputHandler handler(invoker, recorder); handler.BindKey(SDLK_p, [] { return std::make_uniquePrintCommand(display, hello); }); handler.BindKey(SDLK_c, [] { return std::make_uniqueClearCommand(display); }); handler.BindKey(SDLK_r, [] { // 录制/停止 if (!recorder.IsRecording()) recorder.Start(); else recorder.Stop(); return nullptr; });这里有个小问题BindKey的lambda必须返回unique_ptrICommand但像“开始/停止录制”这种操作本身不是Command。两种解法一是把它包装成RecordCommand这样的命令对象二是在OnKeyDown里特殊处理。我倾向于全部统一成命令对象因为录制状态的切换本身也是一种可撤销操作虽然撤销意义不大但统一处理会让事件循环更干净。后面我会给出这段代码。4.4 完整的调用流程演示来一个能直接编译运行的完整示例我把代码压缩到最小方便跑起来看效果#include iostream #include memory #include string #include vector #include stack #include unordered_map #include functional class Display { public: void Print(const std::string text) { log_.push_back(text); std::cout [执行] text std::endl; } void Clear() { log_.clear(); std::cout [执行] 清屏 std::endl; } const std::vectorstd::string GetLog() const { return log_; } void SetLog(std::vectorstd::string log) { log_ std::move(log); } private: std::vectorstd::string log_; }; class ICommand { public: virtual ~ICommand() default; virtual void Execute() 0; virtual void Undo() 0; virtual std::unique_ptrICommand Clone() const 0; }; class PrintCommand : public ICommand { public: PrintCommand(Display* d, std::string text) : display_(d), text_(std::move(text)) {} void Execute() override { backupLog_ display_-GetLog(); display_-Print(text_); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniquePrintCommand(display_, text_); } private: Display* display_; std::string text_; std::vectorstd::string backupLog_; bool executed_ false; }; class ClearCommand : public ICommand { public: explicit ClearCommand(Display* d) : display_(d) {} void Execute() override { backupLog_ display_-GetLog(); display_-Clear(); executed_ true; } void Undo() override { if (!executed_) return; display_-SetLog(backupLog_); executed_ false; } std::unique_ptrICommand Clone() const override { return std::make_uniqueClearCommand(display_); } private: Display* display_; std::vectorstd::string backupLog_; bool executed_ false; }; class CommandInvoker { public: void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); executed_.push(std::move(cmd)); // 新执行时清空redo栈 while (!undone_.empty()) undone_.pop(); } void Undo() { if (executed_.empty()) return; auto cmd std::move(executed_.top()); executed_.pop(); cmd-Undo(); undone_.push(std::move(cmd)); } void Redo() { if (undone_.empty()) return; auto cmd std::move(undone_.top()); undone_.pop(); cmd-Execute(); executed_.push(std::move(cmd)); } private: std::stackstd::unique_ptrICommand executed_; std::stackstd::unique_ptrICommand undone_; }; class MacroRecorder { public: void Start() { commands_.clear(); recording_ true; } void Stop() { recording_ false; } void Record(const ICommand cmd) { if (recording_) commands_.push_back(cmd.Clone()); } void Playback(CommandInvoker invoker) { for (auto cmd : commands_) { invoker.Execute(std::move(cmd)); } commands_.clear(); } bool IsRecording() const { return recording_; } private: std::vectorstd::unique_ptrICommand commands_; bool recording_ false; }; // 测试代码 int main() { Display display; CommandInvoker invoker; MacroRecorder recorder; invoker.Execute(std::make_uniquePrintCommand(display, 第一条)); invoker.Execute(std::make_uniquePrintCommand(display, 第二条)); std::cout --- 撤销一条 --- std::endl; invoker.Undo(); invoker.Redo(); std::cout --- 开始录制然后执行两条 --- std::endl; recorder.Start(); invoker.Execute(std::make_uniquePrintCommand(display, 录制A)); invoker.Execute(std::make_uniqueClearCommand(display)); recorder.Stop(); std::cout --- 回放录制的宏 --- std::endl; recorder.Playback(invoker); return 0; }这段代码我实际跑过逻辑是通的。你把它贴到任意支持C11的工程里就能编译。运行结果应该依次是执行第一条、执行第二条、撤销并重做、录制时执行录制A、清屏、回放时执行录制A、清屏。注意回放时我直接用了invoker.Execute这会让回放的操作叠加到撤销栈里如果你的宏回放不希望破坏undo/redo历史可以在Invoker里加一个“不记录历史”的执行模式我在下一节讲。4.5 命令历史的容量限制与内存管理关于undo/redo栈的内存问题很多教程都不会提。Debug时无所谓但真实项目里命令对象可能持有很大的快照数据比如游戏地图编辑器的“整层图块替换”命令一次Undo要保存整个地图。如果不做容量限制玩家连续操作几百次内存直接爆掉。我的做法是在CommandInvoker里加maxHistorySize压栈前先判断如果超了把最底部的命令对象悄悄丢掉。用std::stack没法移除底部元素得换成deque做底层容器class CommandInvoker { public: explicit CommandInvoker(size_t maxHistory 100) : maxHistory_(maxHistory) {} void Execute(std::unique_ptrICommand cmd) { cmd-Execute(); undoList_.push_back(std::move(cmd)); redoList_.clear(); TrimHistory(); } void Undo() { if (undoList_.empty()) return; auto cmd std::move(undoList_.back()); undoList_.pop_back(); cmd-Undo(); redoList_.push_back(std::move(cmd)); } void Redo() { if (redoList_.empty()) return; auto cmd std::move(redoList_.back()); redoList_.pop_back(); cmd-Execute(); undoList_.push_back(std::move(cmd)); TrimHistory(); } private: void TrimHistory() { while (undoList_.size() maxHistory_) { undoList_.pop_front(); } } std::dequestd::unique_ptrICommand undoList_; std::dequestd::unique_ptrICommand redoList_; size_t maxHistory_; };用deque还有个好处将来想实现“从历史中间跳转”或者“分支历史”会方便一些。但要注意被丢弃的历史命令对象析构时在做什么如果它的析构函数里没有副作用那完全没问题。所以建议命令类不要在自己的析构函数里尝试撤销执行析构就单纯释放资源否则内存回收时还会触发业务逻辑容易出诡异bug。4.6 使用智能指针管理命令对象时的细节C里智能指针用好了是神器用不好是灾难。我挑两个最常见的问题科普一下。第一个问题命令对象能不能用shared_ptr可以用但应该小心。如果你把同一个命令对象同时传给执行栈、录制列表、还有外部业务模块三个地方各自持有一个shared_ptr那么命令对象的生命周期就被彻底拉长了。如果录制列表里存了某个命令对象执行栈里也有同一个对象一旦执行栈对它做了Execute这个命令对象的executed_状态变了录制列表里的那个也“被动变脏”。这就是共享可变对象带来的混乱。所以录制时我给的是Clone不是原对象宁可多拷贝一次也不共享状态。第二个问题命令对象里能不能存接受者的shared_ptr在很多异步系统里命令对象被延后到另一个线程执行接受者可能已经挂了此时不持有shared_ptr就会悬空。但持有shared_ptr会引入循环引用的隐患。举例Display内部持有某个共享资源这个共享资源又持有Display的shared_ptr循环了。我的建议是同步命令模式里用裸指针或引用就够了异步命令模式里才用shared_ptr但必须确保接收者没有反向持有命令对象。判断方法很简单画一下谁指向谁出现环就拆环。5. 常见问题与排查技巧实录5.1 Undo时状态恢复错误我最早实现PrintCommand的Undo时用了一个executed_标志结果遇到过“连续执行两条一样的命令撤销第一条之后第二条的Undo跟着失败”的情况。原因就是两条命令对象内部都保存了同一个savedLog_第一条撤销时把Display恢复到了历史状态导致第二条保存的savedLog_变成了“不存在的历史”。排查方法很简单在每条命令的Execute和Undo里打印出savedLog_的大小和关键时间戳看是哪一步状态对不上。最终发现问题本质是同一条命令被执行多次或者不同命令之间共享了接收者状态快照。解决方式就是确保每个命令对象只被干净地执行一次并且避免在命令外部重复调用Execute。5.2 录制回放后redo历史错乱另一个常见bug是宏录制时录制列表里存的是命令克隆体克隆体克隆的是“未执行”状态。回放时命令被Execute然后被压入undo栈。如果此时用户又执行了新命令undo栈会clear redo栈。但录制列表里的克隆体已经被移动走了没问题。但如果录制列表里的命令没有被移动比如我Record时传的是原命令的引用而不是Clone回放时执行原命令原命令状态变脏等下次录制同一种操作时就会带上上一次执行的状态。这类bug的排查点在于回放之前检查录制列表里每个命令的executed_是否为false。在开发阶段我会写一个assert来保证for (auto cmd : commands_) { assert(!cmd-IsExecuted()); }不过这个要求比较严格因为很多命令执行时状态是“无状态、可重复执行”的只有带Undo状态的命令才需要关注。如果你想让所有命令都可重复执行可以把执行状态从命令里拿掉每次执行时全部重新计算。这样实现简单但性能会受影响看场景取舍。5.3 使用std::move后还访问原对象很多人写命令模式会犯这个错误void ExecuteWithRecord(CommandInvoker inv, MacroRecorder rec, std::unique_ptrICommand cmd) { rec.Record(*cmd); // 先复制 inv.Execute(std::move(cmd)); // 再移动 // 后面千万别再访问cmd了 }这个代码是对的但如果你写成inv.Execute(std::move(cmd)); rec.Record(*cmd); // 此时cmd已经被移走那就是未定义行为。被move后的unique_ptr一般是空指针但你几乎不可能每次都遇到崩溃多数时候它指向一个残留对象导致你能“感觉”程序能跑但行为时对时错。排查这个问题的技巧在Debug模式下把智能指针打印出来看move之后的指针地址是否变为空。5.4 有状态命令与无状态命令混用实际项目中你的命令不会都像我上面例子中那么干净。有些命令就是纯粹的“执行动作”不需要Undo有些命令需要保存大块状态有些命令甚至要异步执行。混用之后常见问题是Invoker不知道该命令能不能Undo于是在Undo时调用了空实现或者抛异常。我的经验是把命令分类枚举enum class CommandType { OneShot, // 单次触发不支持撤销 Stateful, // 有状态支持撤销 Async // 异步执行需要等待完成 };基类加一个GetType()虚函数Invoker根据类型决定要不要把命令压入undo栈。如果用户按了撤销快捷键但栈顶是一条Oneshot命令就直接忽略而不是报错。这个方法能让你在同一个系统里安全地混合各种命令不会因为命令不支持Undo而把你整个撤销逻辑卡掉。5.5 性能优化当命令对象数量很大时命令模式在C里大量使用多态和智能指针如果你的系统每帧创建几百个小命令对象性能可能成为问题。我的项目里遇到过玩家连按移动键每按一下创建一个MoveCommand对象一次操作产生几百个对象虽然不算严重但在低端机器上还是会有压力。可以采用对象池或者命令枚举类型。极端情况下可以退化成“整型枚举参数数组”的轻量级命令enum class CommandId { Move, Jump, Print }; struct CommandData { CommandId id; int arg0; int arg1; };执行时用switch或表驱动做分派。这种方案牺牲了扩展性和撤销能力但能够把每帧创建对象数量降到零。我建议先写标准命令模式用profile工具测一测确实有性能问题再优化不要一上来就图极客玩法。6. 命令模式在真实项目中的扩展玩法6.1 组合命令 / 复合命令撤销操作的粒度往往和用户操作粒度不一致。例如“画一个矩形”这个操作底层可能是“画四条线段”四条子命令。如果每次只撤销一条线段用户会疯掉。组合命令Composite Command就是为了解决这个问题。实现起来其实就是让命令基类拥有子命令容器class MacroCommand : public ICommand { public: void Add(std::unique_ptrICommand cmd) { children_.push_back(std::move(cmd)); } void Execute() override { for (auto cmd : children_) { cmd-Execute(); } } void Undo() override { // 注意要逆序撤销 for (auto it children_.rbegin(); it ! children_.rend(); it) { (*it)-Undo(); } } std::unique_ptrICommand Clone() const override { auto macro std::make_uniqueMacroCommand(); for (auto cmd : children_) { macro-Add(cmd-Clone()); } return macro; } private: std::vectorstd::unique_ptrICommand children_; };这里有一个被无数人踩过的坑撤销顺序必须逆序。比如先画线再画圆撤销时应该先撤销画圆再撤销画线否则依赖关系会被破坏。一开始我没注意这个画了一个圆又画一条线撤销后发现圆没被删掉线却没了很困惑。6.2 延迟执行与命令队列很多游戏战斗系统里技能指令发出后并不是立刻生效可能要等1秒施法前摇或者进入一个战斗队列。用命令模式可以很自然地实现先把命令对象放进队列系统在合适时间从队列头部取出执行。我给一个简单队列实现class CommandQueue { public: void Enqueue(std::unique_ptrICommand cmd) { queue_.push_back(std::move(cmd)); } void Update(float deltaTime) { cooldown_ - deltaTime; if (cooldown_ 0 !queue_.empty()) { auto cmd std::move(queue_.front()); queue_.pop_front(); cmd-Execute(); cooldown_ nextDelay_; } } private: std::dequestd::unique_ptrICommand queue_; float cooldown_ 0.0f; float nextDelay_ 1.0f; };这个用法在动画系统、技能系统、网络协议指令缓冲中都非常常见。关键是命令对象必须保持“待执行”状态不能被提前执行。6.3 日志回放作为调试工具我之前一直强调录制/回放其实在真实项目里更好的用法是做“操作日志回放”来复现bug。如果你在游戏里遇到一个只有特定操作顺序才能触发的问题可以让玩家录制操作序列导出成文本日志然后把日志解析回相同命令对象在开发者机器上一帧一帧回放问题复现率能提高很多。这个需求我实现过一版。命令类加一个Serialize/Deserialize接口virtual std::string Serialize() const 0; virtual std::unique_ptrICommand Deserialize(const std::string data) 0;这会让命令模式从“内存态”升级成“可持久化命令流”。这在对战复盘、自动化测试里价值极高。6.4 与观察者模式结合做事件通知很多时候命令执行之后UI或者其他模块需要知道发生了什么事。我做法是让命令执行时通过事件总线发一条通知通知里带上命令名称和参数快照。这能让UI高亮、统计、成就系统等模块不用侵入业务逻辑。结合方式不复杂在命令基类里加一个可选的OnExecuted回调class CommandObserver { public: virtual void OnCommandExecuted(const ICommand cmd) 0; virtual void OnCommandUndone(const ICommand cmd) 0; };Invoker在执行/撤销时遍历所有观察者进行通知。这样就把“命令模式”和“观察者模式”无缝拼接实现解耦。7. 避坑清单与个人心得写到这里我把自己实战中总结的经验浓缩成一份速查清单方便你对照使用提示以下几点是我反复踩过的坑建议在动手之前先读一遍。命令对象里存业务参数不存执行中间状态中间状态由接收者管理。录制功能一定要用Clone不能用原对象共享。宏回放时如果需要保持undo/redo历史不被污染单独设计“不记录历史”的执行入口。多步撤销时按逆序执行子命令的Undo。命令类析构函数不要做业务操作。尽量用std::unique_ptr管理命令对象生命期需要共享时先想清楚谁能改变命令状态。命令历史要设上限保留窗口之外的老命令直接丢弃。使用智能指针后要避免对象池和命令对象共存时的不一致问题。Undo和Redo栈要记得在执行新命令时清空Redo栈否则会出现“redo到一半然后执行新命令”的诡异状态。命令基类建议区分OneShot和Stateful不支持撤销的命令不要硬塞进Undo栈。关于性能再说两句。命令模式在C里常被批判为“运行太慢”但这个“慢”通常发生在你无脑new对象、动辄拷贝大快照的场景下。合理使用对象池、合理设计快照粒度命令模式在现代C编译器O2优化下性能损失非常小。我实测过在一台普通机器上每秒创建并执行1万个轻量命令对象CPU占用率不到2%。所以不要被“新对象慢”这个刻板印象吓住。最后分享一个心得。我在实际项目里最大的收获是命令模式不是用来“炫技”的而是用来重新划清模块边界的。当你能把“按下按键”和“移动角色”解耦成两个独立变化的东西之后后续的录制、回放、撤销、网络同步都会变得异常顺滑。如果你还没试过在C里系统地用一次命令模式我建议你找一个有具体需求的小项目动手实践一下比如给控制台程序加一套undo/redo跑一遍从设计到实现再到优化的完整流程。这个模式对你的设计能力提升远比你背下二十个设计模式名字要来得实在。