Command Design Pattern

The Command Design Pattern is a behavioral design pattern that converts a request, command, or action into a stand-alone object containing all information about the request. By decoupling the object that invokes the operation from the object that knows how to perform it, systems achieve dynamic configurability, extensible execution pipelines, request queuing/logging, and native support for undoable operations.

1. Why Do We Need This? (Problem Statement & Status Quo)

In traditional Object-Oriented Programming, when an object (the Invoker or Source) needs another object (the Receiver) to perform an action, it directly invokes the receiver's methods.

Consider a naive implementation of a physical or digital Remote Control controlling smart home devices:

RemoteControl (Source)
   |
   | directly calls light.turnOn()
   v
Light (Receiver)

The Pitfalls of Naive Direct Invocation

1. Tight Coupling: The RemoteControl class directly references concrete classes such as Light, Fan, or AirConditioner.
2. Violation of the Open/Closed Principle (OCP): Whenever a new device is installed (e.g., a SmartHeater) or button behavior must change dynamically, the RemoteControl class itself must be reopened and modified.
3. Inability to Support Dynamic Re-assignment: A button permanently bound to light.turnOn() cannot be dynamically remapped at runtime to control an AirConditioner or run a multi-step macro without structural refactoring.
4. Lack of Operational History: Direct method calls execute instantaneously and vanish. You cannot store, queue, delay, serialize, log, or undo them without adding messy flag logic directly inside the caller or the receiver.

2. Core Mental Model: Encapsulating a Request as an Object

To eliminate direct coupling, the Command pattern introduces an intermediate entity: The Command Object. Instead of the Source speaking directly to the Receiver, the request itself is elevated into a first-class citizen—a distinct object.

Source / Invoker (e.g., Remote Button)
   |
   | calls execute() or undo()
   v
Command Interface / Object (e.g., LightOnCommand)
   |
   | delegates operation: light.on()
   v
Receiver (e.g., Light Hardware / Service)

Real-Life Analogy

Think of dining at a restaurant. You (the Client/Invoker) do not walk into the kitchen to tell the chef (the Receiver) how to cook your meal. Instead, the waiter writes your order onto an Order Slip (the Command Object).

The order slip encapsulates your specific request, holds the details, can be passed around, placed in a queue, logged in an accounting ledger, modified, or even cancelled (Undo) before the kitchen processes it. The kitchen only reads the slip and cooks.

3. Naive vs. Command Architecture

The Naive Architecture (Direct Coupling)

class RemoteControl {
private:
    Light livingRoomLight;
    Fan ceilingFan;
public:
    void pressLightButton() {
        livingRoomLight.on(); // Hardcoded direct dependency
    }
    void pressFanButton() {
        ceilingFan.turnOn();  // Hardcoded direct dependency
    }
};

Critique: Any new device added to the home requires modifying RemoteControl. Runtime dynamic mapping of buttons is impossible.

The Decoupled Command Architecture

The invoker references only a generalized abstract interface (ICommand). It neither knows what the command will do, nor which receiver will fulfill it.

4. Architectural Participants

5. Comprehensive Implementation Walkthrough

The following production-style C++ implementation represents a multi-slot, dynamic, toggle-capable Smart Home Remote Control equipped with state tracking (execute vs. undo).

#include <iostream>
#include <vector>
#include <string>

// ==========================================
// 1. COMMAND INTERFACE
// ==========================================
class ICommand {
public:
    virtual ~ICommand() = default;
    virtual void execute() = 0;
    virtual void undo() = 0;
};

// ==========================================
// 2. RECEIVER CLASSES (Business Logic)
// ==========================================
class Light {
private:
    std::string location;
public:
    explicit Light(std::string loc) : location(std::move(loc)) {}

    void on() {
        std::cout << "[" << location << "] Light is ON.\n";
    }

    void off() {
        std::cout << "[" << location << "] Light is OFF.\n";
    }
};

class Fan {
private:
    std::string location;
public:
    explicit Fan(std::string loc) : location(std::move(loc)) {}

    void on() {
        std::cout << "[" << location << "] Fan is running.\n";
    }

    void off() {
        std::cout << "[" << location << "] Fan is stopped.\n";
    }
};

// ==========================================
// 3. CONCRETE COMMANDS
// ==========================================
class LightCommand : public ICommand {
private:
    Light* light; // Encapsulated Receiver pointer
public:
    explicit LightCommand(Light* l) : light(l) {}

    void execute() override {
        if (light) light->on();
    }

    void undo() override {
        if (light) light->off();
    }
};

class FanCommand : public ICommand {
private:
    Fan* fan; // Encapsulated Receiver pointer
public:
    explicit FanCommand(Fan* f) : fan(f) {}

    void execute() override {
        if (fan) fan->on();
    }

    void undo() override {
        if (fan) fan->off();
    }
};

// ==========================================
// 4. INVOKER CLASS
// ==========================================
class RemoteController {
private:
    int totalSlots;
    std::vector<ICommand*> buttons;
    std::vector<bool> buttonStates; // false = Off/Idle, true = On/Active

public:
    explicit RemoteController(int slots = 4) 
        : totalSlots(slots), 
          buttons(slots, nullptr), 
          buttonStates(slots, false) {}

    ~RemoteController() = default;

    // Dynamically assign or re-bind slots at runtime
    void setCommand(int slot, ICommand* command) {
        if (slot < 0 || slot >= totalSlots) {
            std::cerr << "Error: Invalid remote slot index " << slot << ".\n";
            return;
        }
        buttons[slot] = command;
        buttonStates[slot] = false; // Reset state upon binding new command
    }

    // Single button triggers toggle mechanism: Execute -> Undo -> Execute -> Undo
    void pressButton(int slot) {
        if (slot < 0 || slot >= totalSlots) {
            std::cerr << "Error: Slot out of range.\n";
            return;
        }

        if (buttons[slot] == nullptr) {
            std::cout << "Warning: No command assigned at button slot " << slot << ".\n";
            return;
        }

        // State Machine Toggle:
        if (!buttonStates[slot]) {
            buttons[slot]->execute();
            buttonStates[slot] = true;
        } else {
            buttons[slot]->undo();
            buttonStates[slot] = false;
        }
    }
};

// ==========================================
// 5. CLIENT CODE
// ==========================================
int main() {
    // A. Instantiate Receivers
    Light livingRoomLight("Living Room");
    Fan ceilingFan("Ceiling");

    // B. Instantiate Concrete Commands with bound Receivers
    LightCommand lightCmd(&livingRoomLight);
    FanCommand fanCmd(&ceilingFan);

    // C. Instantiate Invoker with 4 available dynamic slots
    RemoteController remote(4);

    // D. Configure Slots
    remote.setCommand(0, &lightCmd);
    remote.setCommand(1, &fanCmd);

    // E. Execute & Undo via Dynamic Invoker Button Press
    std::cout << "--- Testing Button Slot 0 (Light Toggle) ---\n";
    remote.pressButton(0); // Turns ON
    remote.pressButton(0); // Turns OFF

    std::cout << "\n--- Testing Button Slot 1 (Fan Toggle) ---\n";
    remote.pressButton(1); // Turns ON
    remote.pressButton(1); // Turns OFF

    std::cout << "\n--- Testing Unassigned Slot 2 ---\n";
    remote.pressButton(2); // Outputs no command warning

    return 0;
}

Execution Output

--- Testing Button Slot 0 (Light Toggle) ---
[Living Room] Light is ON.
[Living Room] Light is OFF.

--- Testing Button Slot 1 (Fan Toggle) ---
[Ceiling] Fan is running.
[Ceiling] Fan is stopped.

--- Testing Unassigned Slot 2 ---
Warning: No command assigned at button slot 2.

6. Critical Architectural Questions & Trade-offs

Question 1: Why does the Concrete Command hold the Receiver reference instead of the Abstract Command?

The abstract ICommand represents pure intent: "I am an executable and undoable transaction." It has zero awareness of lights, fans, audio engines, or database connections.

If ICommand held a receiver reference, it would force an artificial inheritance hierarchy onto receivers that have nothing in common. Holding the receiver reference inside the Concrete Command encapsulates domain specifics inside the exact component built to handle them, leaving the core command abstraction clean and invariant.

Question 2: Why not create a generic Appliance parent class for all receivers?

One might ask: "Why have LightCommand, FanCommand, ACCommand? Why not create one generic DeviceCommand that controls an abstract Appliance interface exposing turnOn() and turnOff()?"

While tempting, this often violates the Liskov Substitution Principle (LSP):

• A Light has simple binary states: on() and off().
• A Fan has speed controls (setSpeed(1..5)), oscillations, and timers.
• An AirConditioner requires temperature scaling, humidity modes, swing control, and compressor logic.

Forcing them under a single base class either produces anemic interfaces (where specialized device methods are lost) or bloated interfaces that violate the Interface Segregation Principle (ISP). Dedicated concrete commands cleanly map between generic invocations (execute()) and specialized receiver APIs.

7. Real-World Applications & Extended Capabilities

1. Undo/Redo Stacks in Productivity Software

• Text Editors & IDEs: Every character insertion, deletion, format toggle, or indentation is converted into a command object.
• Graphic Design Tools (e.g., Photoshop): Actions like stroke additions, color adjustments, and layer transforms are pushed onto an execution stack.

2. Configurable Keyboard Shortcuts & Macro Engines

Operating systems and games map physical key events to commands dynamically. Key bindings are essentially invokers that look up an index in a key-command map:

Users can remap keys in the settings menu without modifying game physics or engine code.

3. Transaction Logging & Crash Recovery

Because commands package requests as serialized objects, they can be written to disk (e.g., write-ahead logs in databases). If a server crashes midway through a series of transactions:

1. The system restarts.
2. The log file is read sequentially.
3. Every logged command calls execute() to reconstruct the state accurately.

8. Summary and Key Takeaways

• Decoupled Architecture: The Command pattern completely separates the object requesting an operation (the Invoker) from the object that executes it (the Receiver).
• First-Class Operations: Requests are encapsulated as discrete objects (ICommand), enabling them to be passed as arguments, queued, delayed, or swapped at runtime.
• Open/Closed Principle: New commands, macro routines, and complex execution chains can be introduced into the system without altering existing invoker code.
• Native Undo Capability: By complementing execute() with an inverse operation (undo()), bidirectional state manipulation becomes straightforward.
• Liskov Safety: Concrete commands wrap concrete receivers, preventing forced, brittle inheritance hierarchies across disparate hardware or business models.
• Foundation for Complex Systems: The Command pattern forms the architectural core of GUI action systems, task schedulers, transactional write-ahead logs, and multi-level Undo/Redo histories.