C++命令模式实现请求封装与撤销操作

命令模式通过将请求封装为对象，实现调用者与接收者解耦，支持撤销、重做、命令队列等功能。其核心角色包括命令接口、具体命令、接收者、调用者和客户端。以智能家居灯光控制为例，开灯、关灯操作被封装为命令对象，调用者（如遥控器）无需了解具体执行逻辑，仅通过调用命令的execute()和undo()方法即可完成操作与撤销。该模式适用于GUI应用、事务系统、宏录制等场景，提升系统扩展性与灵活性，但需注意避免过度设计、合理控制命令粒度及管理状态与内存。

在C++中，命令模式（Command Pattern）提供了一种非常实用的机制，它将一个请求封装成一个对象，从而允许我们用不同的请求、队列或者日志来参数化客户端。更重要的是，它为实现复杂系统的撤销（Undo）和重做（Redo）功能提供了坚实的基础，将请求的发送者与接收者彻底解耦，极大地提升了代码的灵活性和可维护性。在我看来，它不仅是一种设计模式，更是一种思维方式的转变，让我们能够以更抽象、更解耦的视角来处理系统中的各种操作。

解决方案

命令模式的核心思想是将“操作”抽象化为一个独立的类。这意味着每一个具体的操作，比如“打开文件”、“保存文档”或者“调整亮度”，都不再是直接调用某个对象的方法，而是被封装成一个实现了统一接口的命令对象。这个命令对象包含了执行该操作所需的所有信息，包括接收者（执行操作的实际对象）以及操作的参数。

一个典型的命令模式实现会包含以下几个关键角色：

1. Command（命令接口）：声明一个用于执行操作的接口，通常包含一个

   execute()

   方法，如果支持撤销，还会包含一个

   undo()

   方法。
2. ConcreteCommand（具体命令）：实现

   Command

   接口，将一个接收者对象和一个或多个操作绑定起来。它负责调用接收者的相应方法。
3. Receiver（接收者）：实际执行操作的对象。它知道如何执行与请求相关的具体业务逻辑。
4. Invoker（调用者）：负责触发命令。它持有一个

   Command

   对象，并在需要时调用其

   execute()

   方法。调用者不需要知道具体命令的实现细节，也不需要知道接收者是谁。
5. Client（客户端）：创建具体命令对象，并设置其接收者。它将命令对象传递给调用者。

让我们通过一个简单的“智能家居灯光控制”的例子来理解：

立即学习“C++免费学习笔记（深入）”；

#include 
#include 
#include 
#include  // 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;
    std::stack> history; // 用于撤销的命令历史栈

public:
    void setCommand(std::shared_ptr cmd) {
        command = cmd;
    }

    void pressButton() {
        if (command) {
            command->execute();
            history.push(command); // 将执行过的命令压入历史栈
        }
    }

    void pressUndo() {
        if (!history.empty()) {
            std::shared_ptr 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 turnOn = std::make_shared(myLight);
    std::shared_ptr turnOff = std::make_shared(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应用程序中，比如一个文本编辑器，用户执行的每一个“剪切”、“粘贴”、“输入字符”都可以是一个命令，而这些命令的序列构成了编辑器的历史，从而可以轻松地实现撤销和重做。

Lifetoon

免费的AI漫画创作平台

下载

实现可撤销操作：命令历史栈的妙用

实现撤销（Undo）和重做（Redo）功能，是命令模式最引人注目的应用之一。其核心在于维护一个命令的历史记录。通常，我们会使用一个或两个栈来管理这些历史命令。

最常见的实现方式是使用一个栈来存储所有已经执行过的命令。每当一个命令被成功执行后，它就被压入这个“已执行命令栈”（

history

undo()

让我们再看看

RemoteControl

pressUndo()

class RemoteControl {
private:
    // ... 其他成员 ...
    std::stack> history; // 用于撤销的命令历史栈

public:
    // ... setCommand 和 pressButton ...

    void pressUndo() {
        if (!history.empty()) {
            std::shared_ptr 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

实现撤销操作时，有几个细节需要注意：

1. 状态保存：

   undo()

   方法需要能够将系统恢复到

   execute()

   方法执行之前的状态。这意味着

   ConcreteCommand

   对象在执行

   execute()

   之前，可能需要保存一些必要的“旧状态”。例如，一个“移动图形”的命令，在

   execute()

   时将图形从 (x1, y1) 移到 (x2, y2)，那么在

   undo()

   时，它就需要知道如何将图形从 (x2, y2) 移回 (x1, y1)。这个 (x1, y1) 就是需要保存的旧状态。
2. 命令的粒度：命令的粒度会直接影响撤销的体验。如果一个命令包含了太多的操作，那么撤销它可能会导致太多的副作用。反之，如果命令粒度太小，可能会导致命令对象过多，增加内存开销。找到一个合适的平衡点很重要。
3. 内存管理：如果命令历史栈存储了大量的命令对象，并且每个命令对象都保存了大量状态，那么内存消耗可能会成为一个问题。在实际应用中，可能需要限制历史栈的大小，或者实现更智能的命令压缩/序列化机制。
4. 不可撤销的操作：并非所有操作都可撤销。例如，一个“保存文件”的操作通常是不可撤销的。在这种情况下，

   Command

   接口的

   undo()

   方法可以抛出异常，或者在具体命令中不实现任何操作。

我个人在实现复杂撤销功能时，会倾向于让每个命令尽可能地“自包含”，即它知道如何执行自己，也知道如何撤销自己，而不需要外部过多干预。这有助于保持代码的清晰和模块化。

命令模式在实际项目中的应用场景与考量

命令模式的应用远不止于简单的灯光控制或文本编辑器的撤销功能。在许多复杂的软件系统中，它都能发挥关键作用：

• GUI 应用程序：这是最经典的应用场景。菜单项、工具栏按钮、快捷键等都可以映射到具体的命令对象。例如，一个“复制”操作，可以是一个

  CopyCommand

  ，它封装了对当前选中文本的复制逻辑。这样，无论是通过菜单点击、工具栏按钮还是

  Ctrl+C

  快捷键，都可以通过调用同一个

  CopyCommand

  的

  execute()

  方法来实现。
• 事务系统：在数据库操作中，一系列相关的操作需要作为一个整体成功或失败。每个数据库操作（如插入、更新、删除）可以封装为一个命令，然后将这些命令放入一个队列中。如果所有命令都成功执行，则提交事务；如果有任何一个命令失败，则可以遍历命令队列，执行它们的

  undo()

  操作来回滚事务。
• 宏录制：许多应用程序允许用户录制一系列操作并将其保存为宏。命令模式在这里非常适用，因为每个用户操作都可以被记录为一个命令对象，当用户回放宏时，只需按顺序执行这些命令即可。
• 请求队列/任务调度：在多线程或分布式系统中，可以将客户端的请求封装为命令对象，然后放入一个队列中，由一个或多个工作线程异步地执行。这样可以实现请求的解耦和负载均衡。
• 游戏开发：玩家的动作（如移动、攻击、施法）可以作为命令对象。这不仅方便实现撤销功能（比如“悔棋”），还可以用于记录游戏过程（回放），甚至实现网络游戏的同步（只传输命令对象）。

在实际项目中采用命令模式时，也需要进行一些考量：

1. 过度设计风险：对于非常简单的系统或功能，引入命令模式可能会增加不必要的复杂性。创建大量的命令类、接口和调用者可能会让代码变得臃肿，反而降低开发效率。我通常会先从最直接的实现开始，只有当出现解耦、撤销、队列化等明确需求时，才会考虑引入命令模式。
2. 命令粒度：如前所述，命令的粒度需要仔细权衡。过大或过小都会带来问题。一个好的命令应该是一个独立的、有意义的原子操作。
3. 状态管理：命令对象需要保存执行操作所需的所有状态，以及用于撤销的旧状态。这可能导致命令对象变得复杂，并且可能增加内存消耗。
4. 并发与线程安全：如果命令在多线程环境中执行，或者命令的接收者是共享资源，那么需要确保命令的执行和撤销操作是线程安全的。这可能涉及到锁机制或其他并发控制手段。
5. 序列化：在某些场景下，你可能需要将命令序列化并存储起来（例如，用于持久化宏或事务日志），这要求命令对象及其包含的状态能够被正确地序列化和反序列化。

总的来说，命令模式是一个功能强大且用途广泛的设计模式。它通过将请求对象化，为我们提供了极大的灵活性和可扩展性，尤其是在需要实现撤销/重做、日志记录、事务处理等复杂行为时，它几乎是一个不可或缺的工具。但和所有设计模式一样，它的应用也需要根据具体场景和需求进行权衡，避免过度工程。