C++命令模式实现请求封装与撤销操作-C++-PHP中文网

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

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

在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应用程序中，比如一个文本编辑器，用户执行的每一个“剪切”、“粘贴”、“输入字符”都可以是一个命令，而这些命令的序列构成了编辑器的历史，从而可以轻松地实现撤销和重做。

AI封面生成器

专业的AI封面生成工具，支持小红书、公众号、小说、红包、视频封面等多种类型，一键生成高质量封面图片。

108

查看详情

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

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

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

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

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

以上就是C++命令模式实现请求封装与撤销操作的详细内容，更多请关注php中文网其它相关文章！