C++命令模式实战：从if-else到撤销重做与回放系统

前阵子接了个小项目一个仿植物大战僵尸的塔防小游戏功能不复杂但有个需求特别折磨人所有的玩家操作都要能回放、能撤销按键绑定还得支持自定义。最初我图省事直接在一个巨大的 handler 函数里堆 if-else每个按钮对应一个分支结果产品经理第三天就提了个需求——“把空格键也绑到暂停上顺便再增加一个跳过回合的快捷键”。我打开那个两百行的 switch 语句深呼吸了三次最终还是决定重写。这时候我才真正痛下决心把 C 里的命令模式从头到尾梳理了一遍。这文章不是讲设计模式教科书是我自己重构这个项目时的完整记录。看完你能明白命令模式的核心价值、在 C 里有哪些落地写法包括经典 C98 的接口继承版和现代 C17 的 std::function 版以及撤销、重做、命令队列这些真正实用的进阶玩法。适合写过一些 C、但还没系统用过设计模式的朋友也适合那些想把代码重构得更干净但不知道从哪下手的同学。1. 命令模式到底解决的是什么问题1.1 为什么一个简单的 if-else 会失控先看一个最常见的反例。假设你要做一个文本编辑器支持复制、粘贴、撤销、加粗、插入图片这些操作。很多人第一个版本会长这样void Editor::handleAction(ActionType type, const std::string data) { if (type ActionType::Copy) { // 复制逻辑几十行 } else if (type ActionType::Paste) { // 粘贴逻辑几十行 } else if (type ActionType::Bold) { // 加粗逻辑 } else if (type ActionType::InsertImage) { // 处理图片文件又是一堆 } // 每加一个新功能这里就多一个分支 // 每加一个快捷键这里就多一个 case }这种写法在小规模 demo 里完全没问题但一旦功能多起来它会同时踩中三个坑第一操作逻辑和触发条件强耦合。键盘快捷键要调这段逻辑菜单栏也要调工具栏按钮还要调每加一个入口就把这段逻辑再包一层。第二没法回放和撤销。如果你想知道用户刚才做了哪几步操作或者想按顺序重放一遍这种代码完全帮不上忙。第三代码膨胀速度远超想象。我见过一个真实项目核心 Controller 里塞了三千行的 switch没人敢动那文件因为牵一发而动全身。1.2 命令模式的本质把请求变成对象命令模式做的事情特别朴素它把“执行一个操作”这件事本身封装成一个对象。以前你调用的是函数现在你创建的是一个命令对象对象里面藏着执行这个操作需要的全部信息和动作。打个比方你以前是当面跟厨师说“来一份宫保鸡丁”命令模式则是把这句话写到一张纸上交给传菜员。纸可以排队、可以记录、可以作废、可以重新提交但最终厨师看到的还是那张纸他不需要知道是谁写的、什么时候写的。C 里实现命令模式本质就是定义了一个统一的接口所有命令都遵守这个接口调用方只需要操作接口指针或 std::function 对象根本不需要关心背后是哪个类在干活。这个转变带来三个直接好处解耦请求的发出者Invoker和执行者Receiver互不认识中间全靠命令对象搭桥。可组合命令对象是普通对象你可以把它丢进 vector、扔进队列、存进文件、甚至可以组合成宏命令。可扩展新增一个操作只需要新增一个命令类不需要改动调用方任何代码。这也是为什么红点指挥系统、游戏技能释放、编辑器撤销重做、任务调度框架都离不开命令模式。1.3 什么时候该用什么时候不该用必须说实话命令模式不是银弹。如果你的项目只有三五个操作且永远不会扩展硬套命令模式反而显得很傻。我的判断标准很简单当你需要满足以下任意一条时才值得引入命令模式需要支持撤销/重做需要把操作记录下来做日志、回放、审计需要把多个操作排队、调度、延迟执行需要把一组操作当成一个整体来执行宏命令需要在不修改现有代码的前提下新增操作类型反过来那些简单的 CRUD、一次性脚本、内部工具用命令模式反而加重了代码负担。新手最常犯的错就是把所有地方都塞进设计模式最后调试起来比不用还痛苦。2. 经典实现接口、命令与调用者2.1 四个核心角色缺一不可命令模式在 C 里的经典结构由四个角色组成搞清楚这四个角色整张图纸就清晰了Command命令基类定义执行操作的统一接口。在 C 里通常是一个抽象基类核心方法是 execute()。ConcreteCommand具体命令继承 Command把某个具体的操作和它的接收者绑定在一起。比如 CopyCommand 就持有 Editor 对象的引用execute() 里写具体的复制代码。Invoker调用者持有命令对象并触发执行。比如一个按钮、一个键盘处理器它只管调用 command-execute()。Receiver接收者真正干活的业务逻辑类。文本编辑器、游戏角色、播放器都算接收者。2.2 一个完整的 C98 风格示例为了照顾还在维护老项目的朋友先用经典写法演示一遍。假设我们做一个简单的文本编辑器支持插入文字和删除文字两个操作。#include iostream #include string #include vector // 1. 接收者真正干活的文本编辑器 class TextEditor { public: void insert(const std::string text) { content_ text; } void erase(int count) { if (count static_castint(content_.size())) { count static_castint(content_.size()); } content_.erase(content_.size() - count, count); } const std::string content() const { return content_; } private: std::string content_; }; // 2. 命令基类 class Command { public: virtual ~Command() default; virtual void execute() 0; }; // 3. 具体命令插入文字 class InsertCommand : public Command { public: InsertCommand(TextEditor editor, std::string text) : editor_(editor), text_(std::move(text)) {} void execute() override { editor_.insert(text_); } private: TextEditor editor_; std::string text_; }; // 4. 具体命令删除文字 class EraseCommand : public Command { public: EraseCommand(TextEditor editor, int count) : editor_(editor), count_(count) {} void execute() override { editor_.erase(count_); } private: TextEditor editor_; int count_; }; // 5. 调用者按钮不管你是什么命令我只会点 class Button { public: void setCommand(Command* cmd) { command_ cmd; } void click() { if (command_) command_-execute(); } private: Command* command_ nullptr; }; int main() { TextEditor editor; InsertCommand insertCmd(editor, Hello, ); EraseCommand eraseCmd(editor, 7); Button btn; btn.setCommand(insertCmd); btn.click(); btn.setCommand(eraseCmd); btn.click(); std::cout editor.content() std::endl; // 输出空字符串 return 0; }看到没Button 完全不知道 editor 的存在它只知道 Command 有一个 execute() 方法。以后想给按钮换个功能比如把删除改成插入只需要 setCommand 一个新的命令对象就行Button 类一行代码都不用改。2.3 经典方案的三个痛点上面的代码结构很标准但我实际用下来经典方案有三个明显的痛点。第一是类爆炸。每新增一种操作就得新建一个类。删除、插入、加粗、斜体、改颜色……类数量线性增长而且每个类的代码量都不大但文件管理和命名就够你烦的。第二个痛点是接口太死板。经典 Command 接口只有一个 execute()但实际需求往往还需要 undo()——撤销操作。如果你一开始没设计好后面加一个撤销方法所有命令类都要改一遍。第三个痛点是样板代码太多。每个命令类无非就是存字段 调 receiver 的方法代码高度相似写起来非常枯燥。所以我在新项目里改用了一个更现代的姿势std::function。3. 现代 C 的正确打开方式std::function 与 lambda3.1 为什么 std::function 能替代虚基类C11 之后有了 lambda 表达式和 std::function一个命令完全可以用一个函数对象表示不再需要为每个操作单独建类。这背后的逻辑很简单命令模式的本质是“把操作封装为对象”而 C 里函数对象本身就是一个对象。std::function 可以存 lambda、函数指针、仿函数用法统一还支持拷贝和移动天然适合放进容器里做队列和栈。对比一下就清楚了。经典方案里你要给一个按钮绑定“插入文字”命令得先写一个 InsertCommand 类然后在 main 里 new 出来。现代方案里直接一行 lambda 就完事button.setCommand([editor, text Hello]() { editor.insert(text); });代码量少了三分之二而且 lambda 捕获列表就是命令的状态清单你一眼就能看出这个命令依赖哪些数据。这对于小项目简直是降维打击。3.2 用 std::function 重构命令模式如果把上一节的编辑器用 std::function 重写结构会清爽很多。直接把命令对象定义为 std::functionvoid()调用者里保存的不再是 Command* 而是一个可调用对象。#include functional #include iostream #include string class TextEditor { public: void insert(const std::string text) { content_ text; } void erase(int count) { if (count static_castint(content_.size())) { count static_castint(content_.size()); } content_.erase(content_.size() - count, count); } const std::string content() const { return content_; } private: std::string content_; }; class Button { public: using Command std::functionvoid(); void setCommand(Command cmd) { command_ std::move(cmd); } void click() { if (command_) command_(); } private: Command command_; }; int main() { TextEditor editor; Button btn; // 插入命令 btn.setCommand([editor]() { editor.insert(Hello, ); }); btn.click(); // 换成删除命令按钮类一行没改 btn.setCommand([editor]() { editor.erase(5); }); btn.click(); std::cout editor.content() std::endl; // 输出 H return 0; }这个版本我实测下来在团队协作里有巨大优势新同事接手代码不需要维护几十个命令类只需要看 lambda 捕获了什么、调用了什么逻辑一目了然。而且 lambda 天生支持按值捕获和按引用捕获命令状态的保存方式比类成员变量灵活得多。3.3 lambda 捕获与生命周期新手最容易翻车用 std::function 实现命令模式虽爽但有几个细节必须注意不然程序极其容易崩溃。最经典的问题是栈上对象被 lambda 捕获后悬空。你在一个函数里创建了一个局部对象它的生命周期马上要结束lambda 里却按引用捕获了它然后没事把 lambda 存到别处回头调用时这个引用已经指向一块已经析构的内存。别问我怎么知道的我调试了整整一个下午最后用 AddressSanitizer 才逮住它。正确的做法是如果命令可能会在捕获对象生命周期之外执行必须按值捕获或者用 shared_ptr 包裹接收者。比如auto editorPtr std::make_sharedTextEditor(); Button btn; btn.setCommand([editorPtr]() { editorPtr-insert(safe); });这个模式下只要命令对象还活着接收者就一定还活着不会出现悬空引用。另一个坑是std::function 的开销。std::function 内部可能产生堆分配如果命令对象的创建和销毁极其频繁比如游戏里每帧都生成命令性能会比虚函数调用慢。不过绝大多数业务场景下这个开销可以忽略不计。真到需要压榨性能的时候再考虑手写小函数对象而不是针对 std::function 过早优化。4. 实战命令栈与撤销重做系统4.1 撤销的核心不在命令在状态说实话命令模式最经典的应用就是撤销和重做。但很多教程只讲了一个单向 execute根本没提怎么撤销。我在实际做小游戏的时候发现撤销的核心不是命令本身而是状态的保存和恢复。两种常见的撤销策略命令对象自带反向操作每条命令除了 execute()还有一个 undo()撤销时调用 undo() 恢复上一步状态。适合操作开销小、容易反算的场景比如文本插入的撤销就是删除。快照式撤销执行操作前先保存整个对象状态比如整个编辑器的字符串撤销时整体恢复。适合操作复杂、反算难的场景比如图片滤镜、复杂排版。我采用的策略是给命令增加一个 undo()因为游戏操作大多可以反向计算。比如“移动角色到 (3,4)”这条命令的撤销就是“把角色移回 (2,4)”。这样撤销栈里存的是命令对象而不是每个命令都要保存一遍完整快照。4.2 完整的撤销重做实现直接上代码。这次我用 std::function 双向栈来实现一个支持撤销重做的编辑器核心正好用到了 C 现代特性。#include functional #include iostream #include stack #include string #include memory class TextEditor { public: void insert(int pos, const std::string text) { if (pos static_castint(content_.size())) pos content_.size(); content_.insert(pos, text); } void erase(int pos, int count) { if (pos count static_castint(content_.size())) { count static_castint(content_.size()) - pos; } content_.erase(pos, count); } const std::string content() const { return content_; } private: std::string content_; }; // 一条可撤销的命令 struct Command { std::functionvoid() execute; std::functionvoid() undo; }; class CommandHistory { public: // 执行并记录命令 void execute(const Command cmd) { cmd.execute(); undoStack_.push(cmd); // 新命令执行后重做栈被清空 while (!redoStack_.empty()) redoStack_.pop(); } bool canUndo() const { return !undoStack_.empty(); } bool canRedo() const { return !redoStack_.empty(); } void undo() { if (!canUndo()) return; auto cmd undoStack_.top(); undoStack_.pop(); cmd.undo(); redoStack_.push(cmd); // 注意这里存的是还能再重做的命令 } void redo() { if (!canRedo()) return; auto cmd redoStack_.top(); redoStack_.pop(); cmd.execute(); undoStack_.push(cmd); } private: std::stackCommand undoStack_; std::stackCommand redoStack_; }; int main() { TextEditor editor; CommandHistory history; // 插入 Hello 到位置 0 std::string inserted Hello; history.execute(Command{ [editor, inserted]() { editor.insert(0, inserted); }, [editor, inserted]() { editor.erase(0, inserted.size()); } }); // 再插入 World 到位置 5 std::string inserted2 World; history.execute(Command{ [editor, inserted2]() { editor.insert(5, inserted2); }, [editor, inserted2]() { editor.erase(5, inserted2.size()); } }); std::cout editor.content() std::endl; // Hello World history.undo(); std::cout editor.content() std::endl; // Hello history.undo(); std::cout editor.content() std::endl; // history.redo(); std::cout editor.content() std::endl; // Hello history.redo(); std::cout editor.content() std::endl; // Hello World return 0; }这里有个很重要的细节当有新的编辑操作发生时重做栈应该被清空。这是所有编辑器的标准行为——你不能在撤销之后做新操作然后再点重做期望它把旧操作重放一遍。新旧操作一旦混合状态就会错乱。代码里我在 execute() 里已经处理了这个逻辑。4.3 撤销系统常见的致命坑讲几个真踩过的坑。第一个坑是命令对象的生命周期。日志系统里我最初用裸指针管理命令结果命令队列里还没执行接收者已经被释放了程序直接段错误。后来全部换成 shared_ptr这个问题才根治。第二个坑是** undo 函数里不能用当前状态来推断旧状态**。比如删除操作的撤销是插入被删的内容但你得提前把被删内容存到命令对象里而不是删除的时候去编辑器里再读一遍——因为此时编辑器内容可能已经被后续命令修改过了。命令对象必须是一个自包含的“时光胶囊”存好自己需要的全部信息。第三个坑是撤销栈的内存。如果每次操作都保存大对象快照撤销栈的内存可能膨胀到几百兆。解决方案是限制撤销栈深度比如最多 100 步、用差分存储或压缩快照。游戏里尤其要注意毕竟内存有限。5. 进阶玩法宏命令、队列与日志5.1 宏命令把多个操作打包成一个操作宏命令是命令模式里最实用的组合技巧。它把一组命令顺序执行对外表现出一个命令的外观。比如“格式化文档”这个操作内部可能要执行十几个子命令但在调用者眼里它就是一个命令。用 std::function 实现宏命令特别优雅class MacroCommand { public: void addCommand(const std::functionvoid() cmd) { commands_.push_back(cmd); } void execute() const { for (const auto cmd : commands_) { cmd(); } } private: std::vectorstd::functionvoid() commands_; };把命令塞进 MacroCommand 之后忘掉它是个组合体继续用调用者那一套接口。如果你的宏命令也要支持撤销就得让子命令各自携带 undo 函数撤销时逆序调用每个子命令的 undo。这里有个细节撤销的顺序必须和执行的顺序相反。先插入文字再删除文字撤销时就得先恢复删除再恢复插入。这个逆序逻辑非常好理解但代码里特别容易被人忽略很多 bug 就是这么来的。5.2 命令队列业务解耦和异步调度命令模式的另一个高频场景是命令队列。你接收了很多操作请求但不想立刻执行可以先把命令对象存进队列由专门的调度器决定什么时候执行、按什么顺序执行。这在实际项目里的价值非常大。拿游戏开发来说玩家点击按钮、按键操作和网络回包可能同时到达如果立刻执行UI 线程会被冻结更稳妥的做法是把所有操作先塞进一个线程安全的命令队列后台线程逐个取出来执行UI 线程只负责入队和刷新。我给小游戏加的“回放系统”就是这么干的把玩家每一步操作序列化成命令对象放进队列回放时按固定节奏依次 execute()。线程安全方面C 里可以给队列加互斥锁或者用无锁队列。我实测下来对大多数项目而言直接在 CommandQueue 里放一个 std::mutex 就足够了比花大力气做无锁方案稳得多。class CommandQueue { public: void push(const std::functionvoid() cmd) { std::lock_guardstd::mutex lock(mutex_); commands_.push(cmd); } void drainAll() { while (true) { std::functionvoid() cmd; { std::lock_guardstd::mutex lock(mutex_); if (commands_.empty()) break; cmd commands_.front(); commands_.pop(); } cmd(); } } private: std::queuestd::functionvoid() commands_; std::mutex mutex_; };5.3 把命令变成日志回放与审计命令模式一个比较高级的玩法是命令日志化。思路是既然命令已经是自包含的对象了那你有没有想过把它序列化存到文件里以后无论是做调试回放、做数据恢复还是做玩家行为审计都可以从日志里重新构建出完整的操作序列。比如游戏里玩家遇到 bug你可以在客户端记录下每一条命令日志错误上报时附上日志测试人员就能精确复现整个操作路径不用再靠用户一句模糊的“我好像点了什么然后它就崩了”。序列化命令需要给每个命令加一个唯一标识和参数列表这一步工程量大一些但收益极高。我记得有一次线上 bug正是靠命令日志定位到的——用户说什么都没干就闪退了日志显示他在 3 分钟内连续调用了 2 万多次“跳过动画”命令直接导致了栈溢出。6. 避坑清单与我的实操建议6.1 最容易踩的六个坑速查版为了让你少走弯路我把踩过的坑整理成一张速查表你可以直接贴在工位旁坑现象原因对策lambda 捕获悬空运行时随机崩溃按引用捕获了已析构对象按值捕获或 shared_ptr 包裹接收者undo 用当前状态推断旧值撤销结果错误命令对象没有自包含所需数据执行前把需要的数据快照存在命令对象里撤销栈无上限内存暴涨程序卡顿没有限制撤销深度限制栈深度或采用差分快照新操作后没清空 redo 栈重做换来错误历史违反了编辑器标准行为execute() 里强制清空 redo 栈命令对象共享状态多个命令互相干扰捕获了同一个可变对象用值拷贝或 immutable 设计回调函数里定义命令作用域结束后命令失效忽略了生命周期命令对象和接收者要用 shared_ptr 管理6.2 三点实操心得帮你少走弯路第一点先想清楚 undo 的语义再动手写 execute。大多数教程只讲 execute但现实项目通常命令一写就要考虑撤销。如果你先写 execute 再补 undo很可能发现状态已经对不上了最后不得不用快照方案强行补救。我的习惯是写命令前先问自己这个操作的可逆行为是什么被覆盖的旧值需要提前保存吗然后一并写进命令里。第二点命令对象尽量做到“小而自包含”。一个命令只做一件事命令里不要调其他业务模块的复杂接口更不要往命令对象里塞一大堆无关的上下文。自包含的命令容易测试、容易序列化、容易复用。测试命令模式最爽的一点就是可以单元测试每个命令——不需要模拟 UI不需要启动整个 appnew 出命令设置接收者然后 execute然后验证状态干净利落。第三点适时拆分命令数据与命令执行器。如果命令的 execute 逻辑特别重可以把执行逻辑抽到一个单独的类里命令对象里只存参数数据和一个执行器的引用。这样做的好处是执行器可以被多个命令复用而命令对象变得非常轻量化拷贝和序列化都更快。至于“什么时候用 std::function什么时候用虚基类”我在项目实践中总结了一条不成文的经验如果命令种类少比如 20 个以内、变化慢用 std::function 足够如果命令框架是一个公共基础设施要支持插件扩展别人需要注册自己的命令类型那就保留虚基类 Command 作为公共接口因为它能更好地跨模块传递也方便做反射和动态加载。两条路线并不互斥遇到复杂系统可以先定义 Command 接口再提供 std::function 到该接口的适配器。最后再分享一个我个人的小习惯我习惯在每个命令对象上提供一个 toDebugString() 方法把命令名和关键参数转成字符串。调试排查时配合日志输出命令序列效率高一倍不止。这个方法只有一行代码的价值但关键时刻能救命。