Command Pattern

Overview

The Command pattern is a behavioral design pattern that turns a request into a stand-alone object that contains all information about the request. This transformation allows you to pass requests as method arguments, delay or queue a request's execution, and support undoable operations.

Intent

• Encapsulate a request as an object, thereby letting you parameterize clients with different requests, queue or log requests, and support undoable operations
• Decouple the object that invokes the operation from the object that knows how to perform it
• Allow requests to be queued, logged, or undone

Problem

Imagine you're working on a text editor application. You want to create buttons for various operations: copy, paste, undo, redo, save, etc. You initially implement this by having each button directly call methods on the editor object.

Problems arise when you need to: - Implement undo/redo functionality - Queue operations for later execution - Log operations for audit purposes - Support keyboard shortcuts and menu items for the same operations - Create macro commands that combine multiple operations

The direct coupling between UI elements and business logic makes the system rigid and difficult to extend.

Solution

The Command pattern suggests that GUI objects shouldn't send requests directly to business logic objects. Instead, you should extract all request details, such as the object being called, the name of the method, and the list of arguments, into a separate command class with a single method that triggers this request.

Command objects serve as links between various GUI and business logic objects. From now on, the GUI object doesn't need to know what business logic object will receive the request and how it'll be processed. The GUI object just triggers the command, which handles all the details.

Structure

Components

1. Command Interface: Declares an interface for executing an operation and optionally undoing it.

2. ConcreteCommand: Implements the Command interface and defines a binding between a Receiver object and an action. Implements execute() by invoking corresponding operations on Receiver.

3. Receiver: Knows how to perform the operations associated with carrying out a request. Any class can serve as a Receiver.

4. Invoker: Asks the command to carry out the request. Doesn't know anything about the concrete command.

5. Client: Creates a ConcreteCommand object and sets its receiver.

Implementation Details

Basic Command Interface

class Command {
public:
    virtual ~Command() = default;
    virtual void execute() = 0;
    virtual void undo() {}
};

Simple Command

A simple command that doesn't require a receiver:

class SimpleCommand : public Command {
private:
    std::string payload_;

public:
    explicit SimpleCommand(std::string payload) 
        : payload_(std::move(payload)) {}

    void execute() override {
        std::cout << "SimpleCommand: " << payload_ << std::endl;
    }
};

Complex Command with Receiver

A complex command that delegates work to a receiver:

class ComplexCommand : public Command {
private:
    std::shared_ptr<Receiver> receiver_;
    std::string paramA_;
    std::string paramB_;

public:
    ComplexCommand(std::shared_ptr<Receiver> receiver,
                   std::string a, std::string b)
        : receiver_(std::move(receiver))
        , paramA_(std::move(a))
        , paramB_(std::move(b)) {}

    void execute() override {
        receiver_->doActionA(paramA_);
        receiver_->doActionB(paramB_);
    }
};

Invoker

The invoker stores and executes commands:

class Invoker {
private:
    std::shared_ptr<Command> onStart_;
    std::shared_ptr<Command> onFinish_;

public:
    void setOnStart(std::shared_ptr<Command> command) {
        onStart_ = std::move(command);
    }

    void setOnFinish(std::shared_ptr<Command> command) {
        onFinish_ = std::move(command);
    }

    void doSomethingImportant() {
        if (onStart_) {
            onStart_->execute();
        }
        // Do important work...
        if (onFinish_) {
            onFinish_->execute();
        }
    }
};

Command History (Undo/Redo)

class CommandHistory {
private:
    std::vector<std::shared_ptr<Command>> history_;
    size_t currentPosition_ = 0;
    bool hasCommands_ = false;

public:
    void executeCommand(std::shared_ptr<Command> command) {
        command->execute();

        // Remove any commands after current position
        if (hasCommands_) {
            history_.erase(
                history_.begin() + 
                static_cast<std::ptrdiff_t>(currentPosition_ + 1), 
                history_.end()
            );
        }

        history_.push_back(command);
        currentPosition_ = history_.size() - 1;
        hasCommands_ = true;
    }

    void undo() {
        if (hasCommands_ && currentPosition_ < history_.size()) {
            history_[currentPosition_]->undo();
            if (currentPosition_ > 0) {
                currentPosition_--;
            } else {
                hasCommands_ = false;
            }
        }
    }

    void redo() {
        if (hasCommands_ && currentPosition_ < history_.size() - 1) {
            currentPosition_++;
            history_[currentPosition_]->execute();
        } else if (!hasCommands_ && !history_.empty()) {
            currentPosition_ = 0;
            history_[currentPosition_]->execute();
            hasCommands_ = true;
        }
    }
};

Real-World Example: Text Editor

Implementation

class InsertTextCommand : public Command {
private:
    std::shared_ptr<TextEditor> editor_;
    std::string text_;
    size_t position_;

public:
    InsertTextCommand(std::shared_ptr<TextEditor> editor,
                      std::string text, size_t position)
        : editor_(std::move(editor))
        , text_(std::move(text))
        , position_(position) {}

    void execute() override {
        editor_->insert(text_, position_);
    }

    void undo() override {
        editor_->deleteText(text_.length(), position_);
    }
};

class DeleteTextCommand : public Command {
private:
    std::shared_ptr<TextEditor> editor_;
    size_t length_;
    size_t position_;
    std::string deletedText_;

public:
    DeleteTextCommand(std::shared_ptr<TextEditor> editor,
                      size_t length, size_t position)
        : editor_(std::move(editor))
        , length_(length)
        , position_(position) {}

    void execute() override {
        deletedText_ = editor_->deleteText(length_, position_);
    }

    void undo() override {
        editor_->insert(deletedText_, position_);
    }
};

Applicability

Use the Command pattern when you want to:

1. Parameterize objects with operations: Command lets you parameterize objects with operations. You can replace a callback function with a Command object.

2. Queue operations: You can queue commands for execution, schedule their execution, or execute them remotely.

3. Implement undo/redo: Commands can store state for reversing their effect. The Command interface must have an added undo operation that reverses the effects of a previous call to execute.

4. Log operations: You can log commands as they're executed and replay them in case of a system crash. By augmenting the Command interface with load and store operations, you can keep a persistent log of changes.

5. Structure a system around high-level operations: You can build a system around high-level operations built on primitive operations. Such structure is common in information systems that support transactions.

Advantages

1. Single Responsibility Principle: You can decouple classes that invoke operations from classes that perform these operations.

2. Open/Closed Principle: You can introduce new commands into the app without breaking existing client code.

3. Undo/Redo: You can implement undo/redo functionality.

4. Deferred execution: You can defer command execution or queue commands.

5. Assemble complex commands: You can assemble a set of simple commands into a complex one (Composite pattern).

6. Logging and auditing: You can log commands for auditing or crash recovery purposes.

Disadvantages

1. Code complexity: The code may become more complicated since you're introducing a whole new layer between senders and receivers.

2. Increased number of classes: Each individual command is a class, which increases the number of classes in your application.

3. Memory overhead: If you're storing command history for undo/redo, it can consume significant memory for large operations.

Relations with Other Patterns

• Chain of Responsibility: Handlers in Chain of Responsibility can be implemented as Commands. In this case, you can execute many different operations over the same context object, represented by a request.

• Memento: You can use Memento together with Command for implementing undo. In this case, commands are responsible for performing various operations over a target object, while mementos save the state of that object just before a command gets executed.

• Strategy: Both patterns can be used to parameterize an object with some action. However, they have different intents:
  • Command is about turning a request into an object with all information needed to perform an action
  • Strategy is about different ways of doing the same thing

• Prototype: You can use Prototype when you need to save copies of Commands into history for undo/redo.

• Composite: Macro commands can be implemented using the Composite pattern.

• Visitor: You can treat Visitor as a powerful version of the Command pattern. Its objects can execute operations over various objects of different classes.

Best Practices

1. Keep commands simple: Each command should encapsulate a single operation. For complex operations, use macro commands.

2. Store minimal state: Commands should store only the minimum state needed to execute and undo the operation.

3. Consider memory usage: If implementing undo/redo, consider the memory impact of storing command history. You may need to limit history size.

4. Use smart pointers: Use smart pointers (std::shared_ptr, std::unique_ptr) for memory management.

5. Make commands immutable: Once a command is created, its parameters shouldn't change.

6. Implement proper undo: Ensure that undo properly reverses the effect of execute. Test undo/redo cycles thoroughly.

7. Consider command serialization: For logging or network transmission, commands should be serializable.

8. Use command queues: For asynchronous operations, use command queues with proper synchronization.

Example Usage Scenarios

1. GUI Applications

// Button click executes a command
void Button::onClick() {
    command_->execute();
}

// Menu item executes the same command
void MenuItem::onSelect() {
    command_->execute();
}

// Keyboard shortcut executes the same command
void onKeyPress(Key key) {
    if (key == Key::Ctrl_Z) {
        history_.undo();
    }
}

2. Transaction System

class TransactionCommand : public Command {
    void execute() override {
        beginTransaction();
        try {
            performOperations();
            commit();
        } catch (...) {
            rollback();
            throw;
        }
    }

    void undo() override {
        rollback();
    }
};

3. Task Scheduler

class TaskScheduler {
    void scheduleCommand(std::shared_ptr<Command> cmd,
                        std::chrono::milliseconds delay) {
        scheduledCommands_.push_back({cmd, delay});
    }

    void executePending() {
        for (auto& [cmd, time] : scheduledCommands_) {
            if (isTimeToExecute(time)) {
                cmd->execute();
            }
        }
    }
};

4. Macro Commands

class MacroCommand : public Command {
private:
    std::vector<std::shared_ptr<Command>> commands_;

public:
    void add(std::shared_ptr<Command> command) {
        commands_.push_back(command);
    }

    void execute() override {
        for (auto& cmd : commands_) {
            cmd->execute();
        }
    }

    void undo() override {
        // Undo in reverse order
        for (auto it = commands_.rbegin(); 
             it != commands_.rend(); ++it) {
            (*it)->undo();
        }
    }
};

Conclusion

The Command pattern is a powerful tool for decoupling the sender of a request from its receiver. It's particularly useful when you need to: - Implement undo/redo functionality - Queue or schedule operations - Log operations for auditing - Support multiple ways to trigger the same operation

While it adds complexity by introducing additional classes, the benefits in terms of flexibility, maintainability, and extensibility often outweigh the costs, especially in applications with complex user interactions or transaction requirements.