命令模式的核心是将调用封装为对象,解耦调用者与接收者,典型结构含command接口、具体命令类和接收者;可用std::function+lambda轻量实现,高频场景宜用模板化零开销方案,undo需在execute前保存足够状态快照。

命令模式的核心是把“调用”变成对象
不是写个函数然后调用它,而是把「谁调用、调用什么、传什么参数」全打包进一个类实例里。这样你就能存起来、排队、撤销、重放——关键在于解耦调用者(比如按钮)和接收者(比如文件处理器)。
典型结构包含三部分:Command 抽象接口、具体命令类(如 SaveCommand)、接收者(如 Document)。调用者只依赖 Command,完全不知道背后是保存还是删除。
常见错误是直接在 execute() 里写业务逻辑,导致命令类膨胀且难以复用。正确做法是让命令持有对接收者的引用,并只转发调用。
-
Command接口必须定义execute()(以及可选的undo()) - 具体命令构造时接收
Receiver*和必要参数(如文件路径),不现场获取 - 避免在命令里 new 接收者——接收者应由上层创建并注入,否则破坏控制流
如何用 std::function + lambda 封装成轻量命令对象
C++11 之后,不必硬写一堆继承类。用 std::function<void></void> 包一层 lambda,就能把任意调用转成可存储、可拷贝的命令对象。
比如你想把 document->save("a.txt") 封装成命令:
auto saveCmd = [&document]() { document->save("a.txt"); };
但注意:lambda 捕获方式决定生命周期风险。用 [&] 可能悬空;用 [=] 又可能深拷贝大对象。稳妥做法是显式捕获指针或 std::shared_ptr:
- 接收者用
std::shared_ptr<document></document>管理,命令中捕获该智能指针 - 参数(如文件名)按值捕获,避免字符串生命周期问题
- 若需 undo,额外存一个
std::function<void></void>回滚操作,不要在execute()里临时构造
带参数的命令怎么避免类型擦除开销
用 std::function 方便,但每次调用有虚函数跳转+内存访问开销。高频场景(如游戏帧循环里的输入命令)要考虑替代方案。
更高效的方式是模板化命令类,把行为和参数类型固化在编译期:
template<typename receiver typename... args>
struct FunctionCommand {
Receiver* receiver;
void (Receiver::*method)(Args...);
std::tuple<args...> args;
void execute() { std::apply([this](auto&&... xs) { (receiver->*method)(xs...); }, args); }
};</args...></typename>
这样零运行时开销,但每个不同签名都会生成新类型,不能统一存进 std::vector<:unique_ptr>></:unique_ptr>。权衡点很明确:
- 需要统一容器管理 → 用
std::function或虚函数基类 - 极致性能且命令种类固定 → 模板命令 + variant 或手动 dispatch
- 混用场景?先用
std::function快速验证逻辑,热点再重构
为什么 undo/redo 容易出状态不一致
命令对象只管执行,但 undo 要求它“记得自己干了什么”。最常踩的坑是:在 execute() 中修改了接收者状态,却没在命令里存下足够信息来还原。
例如 DeleteCommand 执行时删了一行文本,但没把那行内容存进命令对象——undo 就只能瞎猜。解决方法很实在:
- 所有影响状态的操作,必须在
execute()前把“前状态”拍快照(如字符串、坐标、ID 列表) - 快照数据存在命令对象成员里,别依赖接收者自己记(它可能被多个命令共享)
- 如果接收者本身支持 Memento 模式,命令可以只存 memento 对象,而非原始数据
- 多步命令(如“拖拽+缩放”组合)要确保每步 undo 顺序与 execute 相反,且中间状态不可见
真正麻烦的不是封装动作,而是封装“可逆性”。只要有一处命令没存够上下文,整个 redo 链就断了。
C++免费学习笔记(深入):立即使用
在学习笔记中,你将探索 C++ 的入门与实战技巧!











