命令模式通过将请求封装为对象，实现调用者与接收者解耦，支持撤销、重做、命令队列等功能。其核心角色包括命令接口、具体命令、接收者、调用者和客户端。以智能家居灯光控制为例，开灯、关灯操作被封装为命令对象，调用者（如遥控器）无需了解具体执行逻辑，仅通过调用命令的execute()和undo()方法即可完成操作与撤销。该模式适用于GUI应用、事务系统、宏录制等场景，提升系统扩展性与灵活性，但需注意避免过度设计、合理控制命令粒度及管理状态与内存。
在C++中，命令模式（Command Pattern）提供了一种非常实用的机制，它将一个请求封装成一个对象，从而允许我们用不同的请求、队列或者日志来参数化客户端。更重要的是，它为实现复杂系统的撤销（Undo）和重做（Redo）功能提供了坚实的基础，将请求的发送者与接收者彻底解耦，极大地提升了代码的灵活性和可维护性。在我看来，它不仅是一种设计模式，更是一种思维方式的转变，让我们能够以更抽象、更解耦的视角来处理系统中的各种操作。
解决方案
命令模式的核心思想是将“操作”抽象化为一个独立的类。这意味着每一个具体的操作，比如“打开文件”、“保存文档”或者“调整亮度”，都不再是直接调用某个对象的方法，而是被封装成一个实现了统一接口的命令对象。这个命令对象包含了执行该操作所需的所有信息，包括接收者（执行操作的实际对象）以及操作的参数。
一个典型的命令模式实现会包含以下几个关键角色：
-
Command（命令接口）：声明一个用于执行操作的接口，通常包含一个
execute()
方法，如果支持撤销，还会包含一个undo()
方法。 -
ConcreteCommand（具体命令）：实现
Command
接口，将一个接收者对象和一个或多个操作绑定起来。它负责调用接收者的相应方法。 - Receiver（接收者）：实际执行操作的对象。它知道如何执行与请求相关的具体业务逻辑。
-
Invoker（调用者）：负责触发命令。它持有一个
Command
对象，并在需要时调用其execute()
方法。调用者不需要知道具体命令的实现细节，也不需要知道接收者是谁。 - Client（客户端）：创建具体命令对象，并设置其接收者。它将命令对象传递给调用者。
让我们通过一个简单的“智能家居灯光控制”的例子来理解：
立即学习“C++免费学习笔记（深入）”；
#include <iostream>
#include <vector>
#include <stack>
#include <memory> // For std::shared_ptr
// 1. Receiver（接收者）
class Light {
public:
void turnOn() {
std::cout << "Light is ON!" << std::endl;
}
void turnOff() {
std::cout << "Light is OFF!" << std::endl;
}
};
// 2. Command（命令接口）
class Command {
public:
virtual void execute() = 0;
virtual void undo() = 0; // 支持撤销操作
virtual ~Command() = default;
};
// 3. ConcreteCommand（具体命令）
class TurnOnLightCommand : public Command {
private:
Light& light; // 持有接收者引用
public:
TurnOnLightCommand(Light& l) : light(l) {}
void execute() override {
light.turnOn();
}
void undo() override {
light.turnOff(); // 开灯的撤销是关灯
}
};
class TurnOffLightCommand : public Command {
private:
Light& light;
public:
TurnOffLightCommand(Light& l) : light(l) {}
void execute() override {
light.turnOff();
}
void undo() override {
light.turnOn(); // 关灯的撤销是开灯
}
};
// 4. Invoker（调用者）
class RemoteControl {
private:
std::shared_ptr<Command> command;
std::stack<std::shared_ptr<Command>> history; // 用于撤销的命令历史栈
public:
void setCommand(std::shared_ptr<Command> cmd) {
command = cmd;
}
void pressButton() {
if (command) {
command->execute();
history.push(command); // 将执行过的命令压入历史栈
}
}
void pressUndo() {
if (!history.empty()) {
std::shared_ptr<Command> lastCommand = history.top();
history.pop();
lastCommand->undo(); // 执行上一个命令的撤销操作
} else {
std::cout << "No commands to undo." << std::endl;
}
}
};
// 5. Client（客户端）
int main() {
Light myLight; // 接收者
RemoteControl remote; // 调用者
// 创建具体命令对象
std::shared_ptr<Command> turnOn = std::make_shared<TurnOnLightCommand>(myLight);
std::shared_ptr<Command> turnOff = std::make_shared<TurnOffLightCommand>(myLight);
// 设置并执行命令
remote.setCommand(turnOn);
remote.pressButton(); // Light is ON!
remote.setCommand(turnOff);
remote.pressButton(); // Light is OFF!
// 执行撤销
remote.pressUndo(); // Light is ON! (撤销了关灯操作)
remote.pressUndo(); // Light is OFF! (撤销了开灯操作)
remote.pressUndo(); // No commands to undo.
return 0;
}在这个例子中，
RemoteControl（调用者）完全不需要知道它控制的是
Light，也不需要知道
turnOn()或
turnOff()这些具体方法。它只知道它有一个
Command对象，并且可以调用它的
execute()和
undo()。这种解耦，在我看来，是命令模式最核心的魅力所在。
为什么我们需要命令模式？解耦与扩展性的核心价值
我经常听到有人问：“为什么不直接调用对象的方法呢？那样不是更简单吗？”这确实是个好问题。对于一些非常简单的、一次性的操作，直接调用当然没问题。但当系统开始变得复杂，特别是当你需要实现以下功能时，命令模式的价值就会凸显出来：
命令模式的引入，首先解决了调用者与接收者之间的紧密耦合。想象一下，如果你的
RemoteControl直接调用
Light的
turnOn()方法，那么每当你想控制其他设备（比如风扇、电视），你就不得不修改
RemoteControl的代码，增加新的方法，或者用大量的
if-else来判断当前控制的是什么设备。这显然违反了开放-封闭原则。
通过命令模式，
RemoteControl只需要知道它持有一个
Command接口的指针，具体是
TurnOnLightCommand还是
TurnOffFanCommand，它完全不关心。这样一来，你可以轻松地增加新的命令类，而无需修改
RemoteControl的代码，这正是我们所说的“对扩展开放，对修改封闭”。这种灵活性在大型项目中尤其重要，它让代码库更容易维护，也更健壮。
其次，命令模式使得请求可以被当作对象来处理。这意味着你可以将命令存储起来，比如放到一个队列中，实现请求的异步执行；或者记录下来，用于日志记录、事务处理，甚至宏录制。我个人觉得，这种将“行为”对象化的能力，是其实现撤销/重做机制的关键。如果没有将操作封装成独立的对象，你很难追踪并逆转一系列复杂的操作序列。在GUI应用程序中，比如一个文本编辑器，用户执行的每一个“剪切”、“粘贴”、“输入字符”都可以是一个命令，而这些命令的序列构成了编辑器的历史，从而可以轻松地实现撤销和重做。
实现可撤销操作：命令历史栈的妙用
实现撤销（Undo）和重做（Redo）功能，是命令模式最引人注目的应用之一。其核心在于维护一个命令的历史记录。通常，我们会使用一个或两个栈来管理这些历史命令。
最常见的实现方式是使用一个栈来存储所有已经执行过的命令。每当一个命令被成功执行后，它就被压入这个“已执行命令栈”（
history栈）。当用户发起撤销操作时，我们从栈顶弹出一个命令，然后调用它的
undo()方法。
让我们再看看
RemoteControl中的
pressUndo()方法：
class RemoteControl {
private:
// ... 其他成员 ...
std::stack<std::shared_ptr<Command>> history; // 用于撤销的命令历史栈
public:
// ... setCommand 和 pressButton ...
void pressUndo() {
if (!history.empty()) {
std::shared_ptr<Command> lastCommand = history.top();
history.pop();
lastCommand->undo(); // 执行上一个命令的撤销操作
// 如果需要支持Redo，这里需要将lastCommand压入一个Redo栈
} else {
std::cout << "No commands to undo." << std::endl;
}
}
};为了支持重做（Redo），我们需要引入第二个栈，通常称为“已撤销命令栈”（或者
redo栈）。当一个命令从
history栈中弹出并执行
undo()后，它会被压入
redo栈。当用户发起重做操作时，我们从
redo栈中弹出一个命令，然后调用它的
execute()方法，并将其重新压回
history栈。
实现撤销操作时，有几个细节需要注意：
-
状态保存：
undo()
方法需要能够将系统恢复到execute()
方法执行之前的状态。这意味着ConcreteCommand
对象在执行execute()
之前，可能需要保存一些必要的“旧状态”。例如，一个“移动图形”的命令，在execute()
时将图形从 (x1, y1) 移到 (x2, y2)，那么在undo()
时，它就需要知道如何将图形从 (x2, y2) 移回 (x1, y1)。这个 (x1, y1) 就是需要保存的旧状态。 - 命令的粒度：命令的粒度会直接影响撤销的体验。如果一个命令包含了太多的操作，那么撤销它可能会导致太多的副作用。反之，如果命令粒度太小，可能会导致命令对象过多，增加内存开销。找到一个合适的平衡点很重要。
- 内存管理：如果命令历史栈存储了大量的命令对象，并且每个命令对象都保存了大量状态，那么内存消耗可能会成为一个问题。在实际应用中，可能需要限制历史栈的大小，或者实现更智能的命令压缩/序列化机制。
-
不可撤销的操作：并非所有操作都可撤销。例如，一个“保存文件”的操作通常是不可撤销的。在这种情况下，
Command
接口的undo()
方法可以抛出异常，或者在具体命令中不实现任何操作。
我个人在实现复杂撤销功能时，会倾向于让每个命令尽可能地“自包含”，即它知道如何执行自己，也知道如何撤销自己，而不需要外部过多干预。这有助于保持代码的清晰和模块化。
命令模式在实际项目中的应用场景与考量
命令模式的应用远不止于简单的灯光控制或文本编辑器的撤销功能。在许多复杂的软件系统中，它都能发挥关键作用：
-
GUI 应用程序：这是最经典的应用场景。菜单项、工具栏按钮、快捷键等都可以映射到具体的命令对象。例如，一个“复制”操作，可以是一个
CopyCommand
，它封装了对当前选中文本的复制逻辑。这样，无论是通过菜单点击、工具栏按钮还是Ctrl+C
快捷键，都可以通过调用同一个CopyCommand
的execute()
方法来实现。 -
事务系统：在数据库操作中，一系列相关的操作需要作为一个整体成功或失败。每个数据库操作（如插入、更新、删除）可以封装为一个命令，然后将这些命令放入一个队列中。如果所有命令都成功执行，则提交事务；如果有任何一个命令失败，则可以遍历命令队列，执行它们的
undo()
操作来回滚事务。 - 宏录制：许多应用程序允许用户录制一系列操作并将其保存为宏。命令模式在这里非常适用，因为每个用户操作都可以被记录为一个命令对象，当用户回放宏时，只需按顺序执行这些命令即可。
- 请求队列/任务调度：在多线程或分布式系统中，可以将客户端的请求封装为命令对象，然后放入一个队列中，由一个或多个工作线程异步地执行。这样可以实现请求的解耦和负载均衡。
- 游戏开发：玩家的动作（如移动、攻击、施法）可以作为命令对象。这不仅方便实现撤销功能（比如“悔棋”），还可以用于记录游戏过程（回放），甚至实现网络游戏的同步（只传输命令对象）。
在实际项目中采用命令模式时，也需要进行一些考量：
- 过度设计风险：对于非常简单的系统或功能，引入命令模式可能会增加不必要的复杂性。创建大量的命令类、接口和调用者可能会让代码变得臃肿，反而降低开发效率。我通常会先从最直接的实现开始，只有当出现解耦、撤销、队列化等明确需求时，才会考虑引入命令模式。
- 命令粒度：如前所述，命令的粒度需要仔细权衡。过大或过小都会带来问题。一个好的命令应该是一个独立的、有意义的原子操作。
- 状态管理：命令对象需要保存执行操作所需的所有状态，以及用于撤销的旧状态。这可能导致命令对象变得复杂，并且可能增加内存消耗。
- 并发与线程安全：如果命令在多线程环境中执行，或者命令的接收者是共享资源，那么需要确保命令的执行和撤销操作是线程安全的。这可能涉及到锁机制或其他并发控制手段。
- 序列化：在某些场景下，你可能需要将命令序列化并存储起来（例如，用于持久化宏或事务日志），这要求命令对象及其包含的状态能够被正确地序列化和反序列化。
总的来说，命令模式是一个功能强大且用途广泛的设计模式。它通过将请求对象化，为我们提供了极大的灵活性和可扩展性，尤其是在需要实现撤销/重做、日志记录、事务处理等复杂行为时，它几乎是一个不可或缺的工具。但和所有设计模式一样，它的应用也需要根据具体场景和需求进行权衡，避免过度工程。
