Lesson notes

Command Pattern

24/36

The Command Design Pattern — A Complete Visual Guide

What you will walk away with: A deep, intuitive understanding of the Command pattern — not just what it is, but why it exists, when to reach for it, and how the world's best engineering teams use it every day. We will build understanding brick by brick, never skipping a step.

Before We Write a Single Line of Code

Let us have a conversation first.

Have you ever used Ctrl+Z?

Of course you have. You typed something wrong, pressed Ctrl+Z, and it disappeared. Magic. Now think about this — how does the software know what to undo? It does not just delete the last character. It reverses an entire operation. Sometimes a complex one.

That is the Command pattern at work.

Have you ever wondered how a game records and replays your inputs?

You play a match. The game records every button press. Later it replays the exact same match. How? Every input — move left, jump, shoot — was stored as an object. Those objects were replayed in sequence.

That is the Command pattern at work.

Have you ever used a job queue? A print queue, a message queue, a task scheduler?

A task goes in. A worker picks it up later. The task does not execute immediately — it waits. How does the queue store "a task that can be executed later"? As an object with an execute() method.

That is the Command pattern at work.

💡 Key Insight Before We Proceed

The Command pattern is not about commands in the English sense — it is about turning actions into objects. Once an action is an object, you can store it, pass it around, queue it, log it, undo it, replay it.

Chapter 1 — Feel the Problem First

Imagine you are using Microsoft Word.

You type "Hello World". Then you make it bold. Then you make it italic. Then you press Ctrl+Z three times and everything goes back to blank.

Simple. You have done this a thousand times.

Now I want you to think like an engineer. How does Word remember what to undo?

It is not magic. Somewhere in Word's code, there is a list. Every time you do something, an entry goes into that list. When you press Ctrl+Z, Word looks at the last entry in the list and reverses it.

Okay. So far so good. Now the real question — what exactly is inside each entry in that list?

Think about it. Entry #2 is "bold was applied". But how do you store "bold was applied" in a list? A list stores objects. So this entry must be an object! AHA Moment

What does that object need to know?

That object — the thing that knows what was done AND how to reverse it — that is a Command object.

Now let us go one level deeper.

You have a text editor. It has a toolbar button for bold. It has a keyboard shortcut Ctrl+B for bold. It has a right-click menu option for bold.

Three different ways to trigger the exact same thing.

All three lead to the same place. But what is that place?

Without Command pattern, each one directly calls the editor:

Looks fine. But now add undo. Each one needs to also record history:

Every single invoker (button, shortcut, menu) is copy-pasting the same two lines. Now add 10 more operations — underline, strikethrough, font size, color, alignment... Every invoker needs to duplicate logic for all 10.

Now imagine your manager says "we are adding a voice command feature." A fourth invoker. You have to go and add the same duplicated logic there too.

This is the problem. Not a crash. Not a bug. Just a design that causes pain — every new invoker duplicates logic, every new feature touches every invoker. It grows like weeds.

Now watch what happens when we flip the thinking.

Instead of the button calling editor.bold() directly — what if the button just held a small object? And that object knew how to do bold AND how to undo bold. The button just calls go() on that object. It does not care what go() does inside.

Now the button knows nothing about bold. It just knows "call go() on whatever object I am holding."

The button, the shortcut, and the menu all point to the same object. Zero duplication. Add a voice command? Give it the same object. Done.

Add a new operation like underline? Create an UnderlineObject. Give it to whichever invokers need it. The existing invokers do not change at all.

That object — the one that wraps an action, knows how to execute it, and knows how to undo it — is called a Command.

That is the entire pattern.

Everything else — macros, queues, logs, replay — is just a natural consequence of the fact that actions are now objects you can hold, store, pass around, and call later.

Lets look at this again. And lets see what we would have written in a real interview under pressure (if we did not know Command Design Pattern) Here is our editor:

Now we need a toolbar with buttons:

Seems fine. Now add keyboard shortcuts:

Now add a context menu:

Now if the interviewer asks to add undo :)

Stop. Look at what is happening.

This is called tight coupling. Your invokers (button, shortcut, menu) know too much about your receiver (editor). They are entangled.

❓ Question to think about:

What if you could wrap editor.bold() inside an object — and just hand that object to any invoker? The invoker would not need to know it is calling bold(). It would just call execute() on whatever object it received.

That is exactly what Command pattern does. Ready to see it?

Chapter 2 — The Insight That Changes Everything

Here is the key mental model shift.

Before Command pattern — actions are method calls:

After Command pattern — actions are objects:

The button no longer calls bold() directly. It holds a Command object and calls execute(). It does not care what execute() does internally. It just calls it.

This one shift unlocks everything:

Any invoker can use any command — just call execute()
Undo? Add undo() to the command interface
Queue operations? Store command objects in a queue
Log operations? Serialize command objects to disk
Replay? Re-call execute() on stored command objects
Macro? Group multiple command objects, call execute() on all of them

Chapter 3 — The Four Players, One at a Time

The Command pattern has four roles. Let us meet them one by one — slowly, with full context.

Player 1 — The Command Interface

This is the contract. Every action in your system will implement this interface.

That is literally it. Two methods. That is the entire interface.

Why undo()? Because the most powerful feature of Command pattern is undoability. Every command knows how to reverse itself.

Why virtual ~Command()? Because we will store commands through base class pointers (Command*), and we need the destructor to be virtual so the correct derived destructor is called.

Player 2 — The Receiver

The receiver is the object that actually does the real work. It has no knowledge of commands whatsoever. It is a pure domain object.

Notice: TextEditor knows nothing about Command, BoldCommand, or any invoker. It is completely isolated. This is good — it can be tested independently.

Player 3 — Concrete Commands

These are the actual command implementations. Each one:

Holds a reference to the receiver
Knows exactly what to call on the receiver in execute()
Knows exactly how to reverse it in undo()

❓ Quick Check — Why does BoldCommand hold a reference to TextEditor?

Because the command needs to delegate work to the receiver when execute() is called. Without the reference, it cannot reach the receiver. The reference is injected at construction time — this is dependency injection in its simplest form.

Player 4 — The Invoker

The invoker triggers commands. It knows nothing about the receiver. It only knows the Command interface.

Look at what the invoker does NOT do:

It does not call editor.bold()
It does not know what TextEditor is
It does not know what BoldCommand is — it only knows Command

This is the entire power of the pattern. The invoker is completely generic. You can plug in any command — now or in the future — and the invoker needs zero changes.

Chapter 4 — Putting It All Together, Line by Line

Now let us write the complete working program. We will go line by line.

Output:

❓ Check your understanding:

When we call invoker.undo() the second time, what chain of calls happens?

Answer:

invoker.undo() is called

Invoker looks at top of history stack — finds BoldCommand

Calls boldCmd.undo()

BoldCommand::undo() calls editor.removeLast(6)

[BOLD] is removed from content

Command is popped from stack

Chapter 5 — The Redo Stack

Once you have undo, redo is a natural extension. When you undo a command, instead of discarding it, move it to a redo stack.

💡 Why does a new action clear the redo stack?

Think about it from the user's perspective. You type "Hello", undo it (empty again), then type "World". Can you now redo "Hello"? No — "Hello" is gone. The timeline branched. There is only one timeline — the redo stack represents a future that was abandoned the moment you took a new action.

Chapter 6 — The Macro Command

A Macro Command is a command that contains other commands. When you call execute() on a macro, it calls execute() on all its children. When you call undo(), it reverses them in reverse order.

Usage:

❓ Why must undo be in reverse order?

Imagine you execute: Bold → Italic → Underline

The content becomes: [BOLD][ITALIC][UNDERLINE]

To undo, you must remove [UNDERLINE] first (the last applied), then [ITALIC], then [BOLD]. If you undo in forward order, you would try to remove [BOLD] from the middle of the string — wrong position, wrong result.

Think of it like a stack of plates. You put them on in order A, B, C. You must take them off in order C, B, A.

Chapter 7 — Real World Deep Dive: Adobe Photoshop

Photoshop's History panel is one of the most famous Command pattern implementations in the world. Every operation — brush stroke, crop, filter, color adjustment — is a Command object.

But here is the advanced part — Photoshop filters cannot always be mathematically reversed. You cannot "un-blur" an image by formula. So Photoshop uses the Memento pattern alongside Command — it saves a snapshot of the pixel buffer before the filter is applied, and restores it on undo.

Chapter 8 — Real World Deep Dive: HFT Trading Systems

In High-Frequency Trading, every market action — place order, cancel order, modify order — is encapsulated as a Command. This is not just good design, it is a regulatory and operational requirement.

Why Command pattern in HFT?

The HFT Invoker — A Lock-Free Command Queue:

In HFT, you cannot afford mutex locks in the hot path. Commands are pushed by the strategy thread and consumed by the order execution thread using a lock-free MPSC (Multi-Producer Single-Consumer) ring buffer:

💡 Why pre-allocate commands?

new and delete (heap allocation) are unpredictable in latency. They can take microseconds — an eternity in HFT where you measure in nanoseconds. By pre-allocating a pool of command objects at startup and reusing them, you eliminate heap allocation from the hot path entirely. This is a fundamental HFT optimization technique.

Chapter 9 — Real World Deep Dive: EDA (Cadence, Synopsys)

In EDA (Electronic Design Automation), simulation runs are extraordinarily expensive — a full chip simulation can take hours or days. Every job (lint check, compilation, synthesis, timing analysis) is managed as a Command.

Chapter 10 — Real World Deep Dive: FAANG (Google Docs)

Google Docs allows multiple users to edit the same document simultaneously. Every keystroke is a Command. When two users edit at the same time, their commands are transformed before being applied so both documents reach the same final state.

This is called Operational Transformation (OT).

Chapter 11 — Command + Thread Pool = Async Task System

The Command pattern is the backbone of every async task system. Worker threads drain a queue of Command objects:

This pattern powers:

AWS Lambda — each invocation is a command dispatched to a worker
Chrome's compositor thread — rendering commands dispatched from UI thread
Kafka consumers — each message triggers a command on a consumer thread
Database connection pools — each query is a command executed by a pool worker

Chapter 12 — Serializable Commands (Logging and Replay)

Commands that can be serialized to disk enable crash recovery, audit logs, and event replay.

Chapter 13 — Command vs Strategy — The Confusion Cleared

These two patterns are often confused. Let us clear this up once and for all.

See the relationship? A Command can use a Strategy internally. They are not competitors — they are collaborators.

Chapter 14 — When to Use, When to Avoid

Chapter 15 — Modern C++ Shortcut: Lambda as Command

In modern C++ (C++11 and beyond), simple commands can be expressed as lambdas stored in std::function — no class needed:

When to use classes vs lambdas:

| Situation | Use | |-----------|-----| | Simple operation, stateless | Lambda | | Operation needs saved state for undo | Class (can store members) | | Operation needs serialization | Class (add serialize()) | | Many similar commands, reused across codebase | Class hierarchy | | Quick prototype | Lambda |

Chapter 16 — Complete Architecture Diagram

Chapter 17 — Summary: The Five Powers of Command

Chapter 18 — Practice Exercises (Levelled)

Level 1 — Calculator with Undo

Implement a calculator supporting Add, Subtract, Multiply, Divide commands with a full undo/redo stack.

Requirements:

Each operation is a Command
undo() reverses the operation mathematically (add 5 → undo subtracts 5)
Full undo/redo history

Starter:

Level 2 — Smart Home Controller

Build a smart home system with:

LightOnCommand / LightOffCommand
ThermostatSetCommand
LockDoorCommand / UnlockDoorCommand
A "Goodnight" MacroCommand that: turns off all lights, sets thermostat to 18°C, locks the door

Bonus: A "Morning" MacroCommand that reverses the Goodnight macro.

Level 3 — Simplified Git

Implement a versioned file system:

CommitCommand — saves a snapshot of current files
RevertCommand — restores a previous commit
BranchCommand — creates a named branch (fork of history)

Hint: Use the Memento pattern for snapshots.

Level 4 — HFT Order Book (Advanced)

Build a simplified trading command system:

PlaceOrderCommand with pre-allocated memory pool (no heap in hot path)
CancelOrderCommand
A lock-free SPSC ring buffer as the command queue
rdtsc-based latency measurement — measure time from submit to execute
Serialize every command to a log file for audit

Level 5 — Distributed Command Log

Build a command log that:

Serializes commands to disk on every execute
On startup, reads the log and replays all commands to restore state
Supports "time travel" — replay up to a given timestamp

This is how databases implement crash recovery (WAL — Write-Ahead Log).

Final Words

The Command pattern is one of those patterns you will use everywhere once you see it. Every undo stack, every job queue, every audit log, every macro system — it is Command under the hood.

The next time you press Ctrl+Z in any application, you will know exactly what is happening. The next time you submit a job to a queue, you will know it is a Command being stored for later execution. The next time you see a distributed system with event replay, you will recognise the serialized Command log.

That is what understanding patterns gives you — X-ray vision into the systems around you.

What to do next:

Implement Level 1 without looking at the solution

Read the source code of an open-source editor (VSCode, Vim) and find their command/action system

Look at how Kafka consumer offsets work — it is Command + log at scale

Come back and attempt Level 4 after you have read about lock-free data structures

Lesson notes

Command Pattern

24/36

The Command Design Pattern — A Complete Visual Guide

What you will walk away with: A deep, intuitive understanding of the Command pattern — not just what it is, but why it exists, when to reach for it, and how the world's best engineering teams use it every day. We will build understanding brick by brick, never skipping a step.

Before We Write a Single Line of Code

Let us have a conversation first.

Have you ever used Ctrl+Z?

That is the Command pattern at work.

Have you ever wondered how a game records and replays your inputs?

That is the Command pattern at work.

Have you ever used a job queue? A print queue, a message queue, a task scheduler?

A task goes in. A worker picks it up later. The task does not execute immediately — it waits. How does the queue store "a task that can be executed later"? As an object with an execute() method.

That is the Command pattern at work.

💡 Key Insight Before We Proceed

The Command pattern is not about commands in the English sense — it is about turning actions into objects. Once an action is an object, you can store it, pass it around, queue it, log it, undo it, replay it.

Chapter 1 — Feel the Problem First

Imagine you are using Microsoft Word.

You type "Hello World". Then you make it bold. Then you make it italic. Then you press Ctrl+Z three times and everything goes back to blank.

Simple. You have done this a thousand times.

Now I want you to think like an engineer. How does Word remember what to undo?

It is not magic. Somewhere in Word's code, there is a list. Every time you do something, an entry goes into that list. When you press Ctrl+Z, Word looks at the last entry in the list and reverses it.

TEXT

1You type "Hello World"    →   list gets entry #1
2You press Ctrl+B (bold)   →   list gets entry #2
3You press Ctrl+I (italic) →   list gets entry #3
4
5You press Ctrl+Z          →   list removes entry #3, reverses italic
6You press Ctrl+Z          →   list removes entry #2, reverses bold
7You press Ctrl+Z          →   list removes entry #1, clears text
8

Okay. So far so good. Now the real question — what exactly is inside each entry in that list?

Think about it. Entry #2 is "bold was applied". But how do you store "bold was applied" in a list? A list stores objects. So this entry must be an object! AHA Moment

What does that object need to know?

TEXT

1Entry #2 object needs to know:
2
3  - WHAT was done       →  "bold was applied"
4  - HOW TO REVERSE IT   →  "remove bold"
5

That object — the thing that knows what was done AND how to reverse it — that is a Command object.

Now let us go one level deeper.

You have a text editor. It has a toolbar button for bold. It has a keyboard shortcut Ctrl+B for bold. It has a right-click menu option for bold.

Three different ways to trigger the exact same thing.

TEXT

1┌──────────────────────────────────────────────────────────┐
2│                                                          │
3│   [Bold Button]  ──────────────────────────────┐         │
4│                                                │         │
5│   Ctrl+B shortcut ─────────────────────────────┼──▶ ???  │
6│                                                │         │
7│   Right-click → Bold ──────────────────────────┘         │
8│                                                          │
9└──────────────────────────────────────────────────────────┘
10

All three lead to the same place. But what is that place?

Without Command pattern, each one directly calls the editor:

TEXT

1┌──────────────────────────────────────────────────────────┐
2│                                                          │
3│   [Bold Button]  ──────────────────────▶ editor.bold()   │
4│                                                          │
5│   Ctrl+B ───────────────────────────── ▶ editor.bold()   │
6│                                                          │
7│   Right-click Bold ─────────────────── ▶ editor.bold()   │
8│                                                          │
9└──────────────────────────────────────────────────────────┘
10

Looks fine. But now add undo. Each one needs to also record history:

TEXT

1┌──────────────────────────────────────────────────────────┐
2│                                                          │
3│   [Bold Button]  ──▶ editor.bold()                       │
4│                  ──▶ history.add("bold")   ← duplicate   │
5│                                                          │
6│   Ctrl+B         ──▶ editor.bold()                       │
7│                  ──▶ history.add("bold")   ← duplicate   │
8│                                                          │
9│   Right-click    ──▶ editor.bold()                       │
10│                  ──▶ history.add("bold")   ← duplicate   │
11│                                                          │
12└──────────────────────────────────────────────────────────┘
13

Now imagine your manager says "we are adding a voice command feature." A fourth invoker. You have to go and add the same duplicated logic there too.

This is the problem. Not a crash. Not a bug. Just a design that causes pain — every new invoker duplicates logic, every new feature touches every invoker. It grows like weeds.

Now watch what happens when we flip the thinking.

TEXT

1┌──────────────────────────────────────────────────────────┐
2│                                                          │
3│   [Bold Button]  ──▶  BoldObject.go()                    │
4│                             │                            │
5│                             │  internally calls          │
6│                             ▼                            │
7│                        editor.bold()                     │
8│                        history.add(this)                 │
9│                                                          │
10└──────────────────────────────────────────────────────────┘
11

Now the button knows nothing about bold. It just knows "call go() on whatever object I am holding."

TEXT

1┌──────────────────────────────────────────────────────────┐
2│                                                          │
3│   [Bold Button]  ──▶  BoldObject.go()    ┐               │
4│                                          │  ALL THE SAME │
5│   Ctrl+B         ──▶  BoldObject.go()   ─┤  OBJECT       │
6│                                          │               │
7│   Right-click    ──▶  BoldObject.go()    ┘               │
8│                                                          │
9│   No duplication. One object. All invokers use it.       │
10│                                                          │
11└──────────────────────────────────────────────────────────┘
12

The button, the shortcut, and the menu all point to the same object. Zero duplication. Add a voice command? Give it the same object. Done.

Add a new operation like underline? Create an UnderlineObject. Give it to whichever invokers need it. The existing invokers do not change at all.

That object — the one that wraps an action, knows how to execute it, and knows how to undo it — is called a Command.

That is the entire pattern.

Everything else — macros, queues, logs, replay — is just a natural consequence of the fact that actions are now objects you can hold, store, pass around, and call later.

Lets look at this again. And lets see what we would have written in a real interview under pressure (if we did not know Command Design Pattern) Here is our editor:

CPP

1class TextEditor {
2public:
3    void bold()   { /* make text bold */   }
4    void italic() { /* make text italic */ }
5};
6

Now we need a toolbar with buttons:

CPP

1class ToolbarButton {
2    TextEditor& editor_;
3    std::string action_;
4public:
5    ToolbarButton(TextEditor& editor, std::string action)
6        : editor_(editor), action_(std::move(action)) {}
7
8    void click() {
9        if (action_ == "bold")   editor_.bold();
10        if (action_ == "italic") editor_.italic();
11    }
12};
13

Seems fine. Now add keyboard shortcuts:

CPP

1class KeyboardShortcut {
2    TextEditor& editor_;
3    std::string action_;
4public:
5    void press() {
6        if (action_ == "bold")   editor_.bold();   // copy-paste
7        if (action_ == "italic") editor_.italic();  // copy-paste
8    }
9};
10

Now add a context menu:

CPP

1class ContextMenu {
2    TextEditor& editor_;
3public:
4    void selectBold()   { editor_.bold(); }   // again
5    void selectItalic() { editor_.italic(); } // again
6};
7

Now if the interviewer asks to add undo :)

CPP

1// So Now every single invoker needs to know about undo. So they all will have to store in history the action they are performing. Below is the pseudo code for the same
2
3void click() {
4    if (action_ == "bold") {
5        editor_.bold();
6        history_.push("bold"); // every invoker duplicates th
7

Stop. Look at what is happening.

TEXT

1                    ┌─────────────────────────────────┐
2                    │         THE PROBLEM             │
3                    └─────────────────────────────────┘
4
5  ToolbarButton ──────────────────────────────▶ TextEditor
6       │           knows bold(), italic()           │
7       │           knows undo logic                 │
8       │                                            │
9  KeyboardShortcut ───────────────────────────▶ TextEditor
10       │           knows bold(), italic()           │
11       │           knows undo logic                 │
12       │                                            │
13  ContextMenu ────────────────────────────────▶ TextEditor
14               knows bold(), italic()
15               knows undo logic
16
17  RESULT: Every invoker is tightly coupled to TextEditor.
18          Every invoker duplicates undo logic.
19          Add a new operation? Change every invoker.
20          Add a new invoker? Duplicate all logic again.
21

This is called tight coupling. Your invokers (button, shortcut, menu) know too much about your receiver (editor). They are entangled.

❓ Question to think about:

What if you could wrap editor.bold() inside an object — and just hand that object to any invoker? The invoker would not need to know it is calling bold(). It would just call execute() on whatever object it received.

That is exactly what Command pattern does. Ready to see it?

Chapter 2 — The Insight That Changes Everything

Here is the key mental model shift.

Before Command pattern — actions are method calls:

TEXT

1Button ──── calls ────▶ editor.bold()
2

After Command pattern — actions are objects:

TEXT

1Button ──── calls ────▶ BoldCommand.execute() ──── delegates ────▶ editor.bold()
2

The button no longer calls bold() directly. It holds a Command object and calls execute(). It does not care what execute() does internally. It just calls it.

This one shift unlocks everything:

Any invoker can use any command — just call execute()
Undo? Add undo() to the command interface
Queue operations? Store command objects in a queue
Log operations? Serialize command objects to disk
Replay? Re-call execute() on stored command objects
Macro? Group multiple command objects, call execute() on all of them

TEXT

1┌──────────────────────────────────────────────────────────────┐
2│                    THE MENTAL MODEL                          │
3│                                                              │
4│   BEFORE:  Invoker ──── directly calls ────▶ Receiver        │
5│                                                              │
6│   AFTER:   Invoker ──── calls execute() ──▶ Command          │
7│                                                 │            │
8│                                                 │            │
9│                                           delegates          │
10│                                                 │            │
11│                                                 ▼            │
12│                                            Receiver          │
13└──────────────────────────────────────────────────────────────┘
14

Chapter 3 — The Four Players, One at a Time

The Command pattern has four roles. Let us meet them one by one — slowly, with full context.

Player 1 — The Command Interface

This is the contract. Every action in your system will implement this interface.

CPP

1class Command {
2public:
3    virtual ~Command() = default;
4    virtual void execute() = 0;
5    virtual void undo()    = 0;
6};
7

That is literally it. Two methods. That is the entire interface.

Why undo()? Because the most powerful feature of Command pattern is undoability. Every command knows how to reverse itself.

Why virtual ~Command()? Because we will store commands through base class pointers (Command*), and we need the destructor to be virtual so the correct derived destructor is called.

TEXT

1┌─────────────────────────────────────┐
2│         «interface»                 │
3│            Command                  │
4├─────────────────────────────────────┤
5│  + execute() : void  [pure virtual] │
6│  + undo()    : void  [pure virtual] │
7└─────────────────────────────────────┘
8         ▲            ▲            ▲
9         │            │            │
10    BoldCommand  ItalicCommand  MacroCommand
11    (concrete)   (concrete)     (concrete)
12

Player 2 — The Receiver

The receiver is the object that actually does the real work. It has no knowledge of commands whatsoever. It is a pure domain object.

CPP

1class TextEditor {
2    std::string content_;
3public:
4    void bold() {
5        content_ += "[BOLD]";
6        std::cout << "Applied bold\n";
7    }
8
9    void italic() {
10        content_ += "[ITALIC]";
11        std::cout << "Applied italic\n";
12    }
13
14    void removeLast(int n) {
15        if (content_.size() >= n)
16            content_.erase(content_.size() - n);
17    }
18
19    std::string getContent() const { return content_; }
20};
21

Notice: TextEditor knows nothing about Command, BoldCommand, or any invoker. It is completely isolated. This is good — it can be tested independently.

Player 3 — Concrete Commands

These are the actual command implementations. Each one:

Holds a reference to the receiver
Knows exactly what to call on the receiver in execute()
Knows exactly how to reverse it in undo()

CPP

1class BoldCommand : public Command {
2    TextEditor& editor_;  // reference to receiver
3public:
4    explicit BoldCommand(TextEditor& editor) : editor_(editor) {}
5
6    void execute() override {
7        editor_.bold();          // delegate to receiver
8    }
9
10    void undo() override {
11        editor_.removeLast(6);   // "[BOLD]" is 6 characters
12    }
13};
14

CPP

1class ItalicCommand : public Command {
2    TextEditor& editor_;
3public:
4    explicit ItalicCommand(TextEditor& editor) : editor_(editor) {}
5
6    void execute() override { editor_.italic(); }
7    void undo()    override { editor_.removeLast(8); } // "[ITALIC]"
8};
9

❓ Quick Check — Why does BoldCommand hold a reference to TextEditor?

Because the command needs to delegate work to the receiver when execute() is called. Without the reference, it cannot reach the receiver. The reference is injected at construction time — this is dependency injection in its simplest form.

Player 4 — The Invoker

The invoker triggers commands. It knows nothing about the receiver. It only knows the Command interface.

CPP

1class CommandInvoker {
2    std::stack<std::unique_ptr<Command>> history_;
3
4public:
5    void execute(std::unique_ptr<Command> cmd) {
6        cmd->execute();                    // run the command
7        history_.push(std::move(cmd));     // save for undo
8    }
9
10    void undo() {
11        if (history_.empty()) return;
12        history_.top()->undo();            // reverse the last command
13        history_.pop();                    // remove from history
14    }
15};
16

Look at what the invoker does NOT do:

It does not call editor.bold()
It does not know what TextEditor is
It does not know what BoldCommand is — it only knows Command

This is the entire power of the pattern. The invoker is completely generic. You can plug in any command — now or in the future — and the invoker needs zero changes.

TEXT

1┌─────────────────────────────────────────────────────────────────┐
2│                    FULL PICTURE                                 │
3│                                                                 │
4│   Client                                                        │
5│     │                                                           │
6│     │── creates ──▶ TextEditor (Receiver)                       │
7│     │── creates ──▶ BoldCommand(editor) (Concrete Command)      │
8│     │── creates ──▶ CommandInvoker (Invoker)                    │
9│     │── wires ────▶ invoker.execute(boldCmd)                    │
10│                                                                 │
11│   Invoker                                                       │
12│     │── calls ────▶ boldCmd.execute()                           │
13│                          │                                      │
14│                          │── delegates ──▶ editor.bold()        │
15│                                                                 │
16│   Invoker (on undo)                                             │
17│     │── calls ────▶ boldCmd.undo()                              │
18│                          │                                      │
19│                          │── delegates ──▶ editor.removeLast(6) │
20└─────────────────────────────────────────────────────────────────┘
21

Chapter 4 — Putting It All Together, Line by Line

Now let us write the complete working program. We will go line by line.

CPP

1#include <iostream>
2#include <memory>
3#include <stack>
4#include <string>
5
6// ─────────────────────────────────────────
7// Step 1: The Command Interface
8// ─────────────────────────────────────────
9class Command {
10public:
11    virtual ~Command() = default;
12    virtual void execute() = 0;
13    virtual void undo()    = 0;
14};
15
16// ─────────────────────────────────────────
17// Step 2: The Receiver
18// ─────────────────────────────────────────
19class TextEditor {
20    std::string content_;
21public:
22    void bold()            { content_ += "[BOLD]";   }
23    void italic()          { content_ += "[ITALIC]"; }
24    void removeLast(int n) { content_.erase(content_.size() - n); }
25    std::string get()      { return content_; }
26};
27
28// ─────────────────────────────────────────
29// Step 3: Concrete Commands
30// ─────────────────────────────────────────
31class BoldCommand : public Command {
32    TextEditor& e_;
33public:
34    explicit BoldCommand(TextEditor& e) : e_(e) {}
35    void execute() override { e_.bold();          }
36    void undo()    override { e_.removeLast(6);   }
37};
38
39class ItalicCommand : public Command {
40    TextEditor& e_;
41public:
42    explicit ItalicCommand(TextEditor& e) : e_(e) {}
43    void execute() override { e_.italic();        }
44    void undo()    override { e_.removeLast(8);   }
45};
46
47// ─────────────────────────────────────────
48// Step 4: The Invoker
49// ─────────────────────────────────────────
50class CommandInvoker {
51    std::stack<std::unique_ptr<Command>> history_;
52public:
53    void execute(std::unique_ptr<Command> cmd) {
54        cmd->execute();
55        history_.push(std::move(cmd));
56    }
57    void undo() {
58        if (history_.empty()) return;
59        history_.top()->undo();
60        history_.pop();
61    }
62};
63
64// ─────────────────────────────────────────
65// Step 5: Client — wires everything
66// ─────────────────────────────────────────
67int main() {
68    TextEditor editor;
69    CommandInvoker invoker;
70
71    std::cout << "Initial: '" << editor.get() << "'\n";
72
73    invoker.execute(std::make_unique<BoldCommand>(editor));
74    std::cout << "After bold:   '" << editor.get() << "'\n";
75
76    invoker.execute(std::make_unique<ItalicCommand>(editor));
77    std::cout << "After italic: '" << editor.get() << "'\n";
78
79    invoker.undo();
80    std::cout << "After undo:   '" << editor.get() << "'\n";
81
82    invoker.undo();
83    std::cout << "After undo:   '" << editor.get() << "'\n";
84
85    return 0;
86}
87

Output:

TEXT

1Initial:      ''
2After bold:   '[BOLD]'
3After italic: '[BOLD][ITALIC]'
4After undo:   '[BOLD]'
5After undo:   ''
6

❓ Check your understanding:

When we call invoker.undo() the second time, what chain of calls happens?

Answer:

invoker.undo() is called

Invoker looks at top of history stack — finds BoldCommand

Calls boldCmd.undo()

BoldCommand::undo() calls editor.removeLast(6)

[BOLD] is removed from content

Command is popped from stack

Chapter 5 — The Redo Stack

Once you have undo, redo is a natural extension. When you undo a command, instead of discarding it, move it to a redo stack.

TEXT

1┌─────────────────────────────────────────────────────────────┐
2│                    UNDO / REDO STACKS                        │
3│                                                              │
4│   After 3 commands executed:                                 │
5│                                                              │
6│   Undo Stack (top = most recent)     Redo Stack             │
7│   ┌────────────┐                     ┌────────────┐          │
8│   │  Italic   │ ◀── top             │            │          │
9│   ├────────────┤                     └────────────┘          │
10│   │   Bold    │                      (empty)                 │
11│   ├────────────┤                                             │
12│   │  Underline│                                              │
13│   └────────────┘                                             │
14│                                                              │
15│   After Ctrl+Z (undo):                                       │
16│                                                              │
17│   Undo Stack                         Redo Stack              │
18│   ┌────────────┐                     ┌────────────┐          │
19│   │   Bold    │ ◀── top             │  Italic   │ ◀── top   │
20│   ├────────────┤                     └────────────┘          │
21│   │  Underline│                                              │
22│   └────────────┘                                             │
23│                                                              │
24│   After Ctrl+Shift+Z (redo):                                 │
25│                                                              │
26│   Undo Stack                         Redo Stack              │
27│   ┌────────────┐                     ┌────────────┐          │
28│   │  Italic   │ ◀── top             │            │          │
29│   ├────────────┤                     └────────────┘          │
30│   │   Bold    │                       (empty again)          │
31│   ├────────────┤                                             │
32│   │  Underline│                                              │
33│   └────────────┘                                             │
34└─────────────────────────────────────────────────────────────┘
35

CPP

1class HistoryManager {
2    std::stack<std::unique_ptr<Command>> undoStack_;
3    std::stack<std::unique_ptr<Command>> redoStack_;
4
5public:
6    void execute(std::unique_ptr<Command> cmd) {
7        cmd->execute();
8        undoStack_.push(std::move(cmd));
9
10        // IMPORTANT: any new action clears the redo stack
11        // (just like in real editors — you cannot redo
12        //  after taking a new action)
13        while (!redoStack_.empty()) redoStack_.pop();
14    }
15
16    void undo() {
17        if (undoStack_.empty()) return;
18        auto cmd = std::move(undoStack_.top());
19        undoStack_.pop();
20        cmd->undo();
21        redoStack_.push(std::move(cmd));  // save for redo
22    }
23
24    void redo() {
25        if (redoStack_.empty()) return;
26        auto cmd = std::move(redoStack_.top());
27        redoStack_.pop();
28        cmd->execute();
29        undoStack_.push(std::move(cmd));  // back to undo stack
30    }
31};
32

💡 Why does a new action clear the redo stack?

Think about it from the user's perspective. You type "Hello", undo it (empty again), then type "World". Can you now redo "Hello"? No — "Hello" is gone. The timeline branched. There is only one timeline — the redo stack represents a future that was abandoned the moment you took a new action.

Chapter 6 — The Macro Command

A Macro Command is a command that contains other commands. When you call execute() on a macro, it calls execute() on all its children. When you call undo(), it reverses them in reverse order.

TEXT

1┌─────────────────────────────────────────────────────────┐
2│                  MacroCommand                            │
3│                                                          │
4│   commands_ = [                                          │
5│     BoldCommand,                                         │
6│     ItalicCommand,                                       │
7│     UnderlineCommand                                     │
8│   ]                                                      │
9│                                                          │
10│   execute() → calls each in order:                       │
11│     1. BoldCommand.execute()                             │
12│     2. ItalicCommand.execute()                           │
13│     3. UnderlineCommand.execute()                        │
14│                                                          │
15│   undo() → reverses in REVERSE order:                    │
16│     1. UnderlineCommand.undo()                           │
17│     2. ItalicCommand.undo()                              │
18│     3. BoldCommand.undo()                                │
19└─────────────────────────────────────────────────────────┘
20

CPP

1#include <vector>
2
3class MacroCommand : public Command {
4    std::vector<std::unique_ptr<Command>> commands_;
5
6public:
7    void add(std::unique_ptr<Command> cmd) {
8        commands_.push_back(std::move(cmd));
9    }
10
11    void execute() override {
12        // execute in order
13        for (auto& cmd : commands_)
14            cmd->execute();
15    }
16
17    void undo() override {
18        // CRITICAL: undo in REVERSE order
19        for (auto it = commands_.rbegin(); it != commands_.rend(); ++it)
20            (*it)->undo();
21    }
22};
23

Usage:

CPP

1TextEditor editor;
2CommandInvoker invoker;
3
4// Create a "format heading" macro
5auto headingMacro = std::make_unique<MacroCommand>();
6headingMacro->add(std::make_unique<BoldCommand>(editor));
7headingMacro->add(std::make_unique<ItalicCommand>(editor));
8
9// Execute the macro as a single command
10invoker.execute(std::move(headingMacro));
11
12// One undo reverses BOTH operations
13invoker.undo();
14

❓ Why must undo be in reverse order?

Imagine you execute: Bold → Italic → Underline

The content becomes: [BOLD][ITALIC][UNDERLINE]

To undo, you must remove [UNDERLINE] first (the last applied), then [ITALIC], then [BOLD]. If you undo in forward order, you would try to remove [BOLD] from the middle of the string — wrong position, wrong result.

Think of it like a stack of plates. You put them on in order A, B, C. You must take them off in order C, B, A.

Chapter 7 — Real World Deep Dive: Adobe Photoshop

Photoshop's History panel is one of the most famous Command pattern implementations in the world. Every operation — brush stroke, crop, filter, color adjustment — is a Command object.

TEXT

1┌──────────────────────────────────────┐
2│      Photoshop History Panel         │
3│                                      │
4│  ▶ Open                              │
5│  ▶ Brightness/Contrast               │
6│  ▶ Gaussian Blur          ◀─ current │
7│    Hue/Saturation                    │
8│    Unsharp Mask                      │
9│                                      │
10│  [grayed out = undone, available     │
11│   for redo]                          │
12└──────────────────────────────────────┘
13

CPP

1// Snapshot of image state (Memento)
2class ImageSnapshot {
3    std::vector<uint8_t> pixelData_;
4    int width_, height_;
5public:
6    ImageSnapshot(const Canvas& canvas)
7        : pixelData_(canvas.pixels()),
8          width_(canvas.width()),
9          height_(canvas.height()) {}
10
11    const std::vector<uint8_t>& pixels() const { return pixelData_; }
12};
13
14// A destructive filter command (cannot be mathematically reversed)
15class GaussianBlurCommand : public Command {
16    Canvas& canvas_;
17    float sigma_;
18    std::unique_ptr<ImageSnapshot> snapshot_; // saved before execute
19
20public:
21    GaussianBlurCommand(Canvas& canvas, float sigma)
22        : canvas_(canvas), sigma_(sigma) {}
23
24    void execute() override {
25        // Save state BEFORE applying filter
26        snapshot_ = std::make_unique<ImageSnapshot>(canvas_);
27        // Apply the blur (destructive operation)
28        canvas_.applyGaussianBlur(sigma_);
29    }
30
31    void undo() override {
32        // Restore from snapshot
33        canvas_.restorePixels(snapshot_->pixels());
34    }
35};
36

TEXT

1┌─────────────────────────────────────────────────────────────────┐
2│          PHOTOSHOP COMMAND LIFECYCLE                            │
3│                                                                 │
4│  User clicks "Gaussian Blur"                                    │
5│         │                                                       │
6│         ▼                                                       │
7│  GaussianBlurCommand created                                    │
8│         │                                                       │
9│         ▼                                                       │
10│  execute() called:                                              │
11│    1. Snapshot current pixels → saved in command object         │
12│    2. Apply blur to canvas                                      │
13│    3. Command pushed to history stack                           │
14│         │                                                       │
15│         ▼                                                       │
16│  User presses Ctrl+Z                                            │
17│         │                                                       │
18│         ▼                                                       │
19│  undo() called:                                                 │
20│    1. Restore pixels from snapshot                              │
21│    2. Command moved to redo stack                               │
22│                                                                 │
23│  Memory note: snapshots can be HUGE (50MB images).             │
24│  Photoshop limits history states to manage RAM.                 │
25└─────────────────────────────────────────────────────────────────┘
26

Chapter 8 — Real World Deep Dive: HFT Trading Systems

Why Command pattern in HFT?

TEXT

1┌─────────────────────────────────────────────────────────────────┐
2│   HFT REQUIREMENTS → COMMAND PATTERN FEATURES                   │
3│                                                                 │
4│   Requirement                    Feature                        │
5│   ─────────────────────────────────────────────────────────     │
6│   Audit log (regulatory)    →    Commands are serializable       │
7│   Replay market events      →    Commands can be re-executed     │
8│   Rate limiting             →    Commands queue in MPSC buffer   │
9│   Undo bad order            →    Commands have undo() method     │
10│   Latency measurement       →    Timestamp on each command       │
11│   Pre-trade risk check      →    Decorator wraps command         │
12└─────────────────────────────────────────────────────────────────┘
13

CPP

1// Receiver — the Order Management System
2class OrderManagementSystem {
3public:
4    std::string placeOrder(const std::string& symbol,
5                           int qty, double price, char side) {
6        std::string orderId = generateOrderId();
7        // Send FIX NewOrderSingle message to exchange
8        sendFIX(orderId, symbol, qty, price, side);
9        return orderId;
10    }
11
12    void cancelOrder(const std::string& orderId) {
13        // Send FIX OrderCancelRequest to exchange
14        sendFIXCancel(orderId);
15    }
16
17    void modifyOrder(const std::string& orderId,
18                     int newQty, double newPrice) {
19        // Send FIX OrderCancelReplaceRequest
20        sendFIXReplace(orderId, newQty, newPrice);
21    }
22};
23
24// Command interface — extended with timestamp and serialization
25class TradingCommand {
26public:
27    virtual ~TradingCommand() = default;
28    virtual void execute()            = 0;
29    virtual void undo()               = 0;
30    virtual std::string serialize()   = 0;   // for audit log
31    virtual int64_t     timestamp()   = 0;   // nanoseconds
32};
33
34// Concrete command — Place Order
35class PlaceOrderCommand : public TradingCommand {
36    OrderManagementSystem& oms_;
37    std::string symbol_;
38    int         qty_;
39    double      price_;
40    char        side_;       // 'B' = buy, 'S' = sell
41    std::string orderId_;    // filled in by execute()
42    int64_t     timestamp_;
43
44public:
45    PlaceOrderCommand(OrderManagementSystem& oms,
46                      std::string symbol,
47                      int qty, double price, char side)
48        : oms_(oms),
49          symbol_(std::move(symbol)),
50          qty_(qty), price_(price), side_(side),
51          timestamp_(nanotime()) {}
52
53    void execute() override {
54        orderId_ = oms_.placeOrder(symbol_, qty_, price_, side_);
55    }
56
57    void undo() override {
58        if (!orderId_.empty())
59            oms_.cancelOrder(orderId_);
60    }
61
62    std::string serialize() override {
63        return "PLACE|" + symbol_ + "|" +
64               std::to_string(qty_) + "|" +
65               std::to_string(price_) + "|" +
66               side_ + "|" + orderId_;
67    }
68
69    int64_t timestamp() override { return timestamp_; }
70};
71

The HFT Invoker — A Lock-Free Command Queue:

TEXT

1┌──────────────────────────────────────────────────────────────┐
2│                HFT COMMAND PIPELINE                          │
3│                                                              │
4│  Strategy Thread(s)          Execution Thread               │
5│  ─────────────────           ────────────────               │
6│                                                              │
7│  PlaceOrderCmd ──┐                                           │
8│  CancelCmd    ───┼──▶ [MPSC Ring Buffer] ──▶ execute()       │
9│  ModifyCmd    ──┘                            │               │
10│                                              ▼               │
11│                                        Audit Logger          │
12│                                        (serialize to disk)   │
13│                                              │               │
14│                                              ▼               │
15│                                         FIX Protocol         │
16│                                         (to exchange)        │
17└──────────────────────────────────────────────────────────────┘
18

CPP

1// Lock-free command queue (simplified SPSC for illustration)
2template<typename T, size_t Size>
3class RingBuffer {
4    std::array<T, Size> buffer_;
5    std::atomic<size_t> head_{0};
6    std::atomic<size_t> tail_{0};
7
8public:
9    bool push(T item) {
10        size_t next = (head_.load(std::memory_order_relaxed) + 1) % Size;
11        if (next == tail_.load(std::memory_order_acquire))
12            return false; // full
13        buffer_[head_] = std::move(item);
14        head_.store(next, std::memory_order_release);
15        return true;
16    }
17
18    bool pop(T& item) {
19        size_t t = tail_.load(std::memory_order_relaxed);
20        if (t == head_.load(std::memory_order_acquire))
21            return false; // empty
22        item = std::move(buffer_[t]);
23        tail_.store((t + 1) % Size, std::memory_order_release);
24        return true;
25    }
26};
27
28// Pre-allocated command pool — zero heap allocation in hot path
29class CommandPool {
30    static constexpr size_t POOL_SIZE = 1024;
31    std::array<PlaceOrderCommand, POOL_SIZE> pool_;
32    std::atomic<size_t> next_{0};
33public:
34    PlaceOrderCommand* acquire() {
35        return &pool_[next_.fetch_add(1) % POOL_SIZE];
36    }
37};
38

💡 Why pre-allocate commands?

new and delete (heap allocation) are unpredictable in latency. They can take microseconds — an eternity in HFT where you measure in nanoseconds. By pre-allocating a pool of command objects at startup and reusing them, you eliminate heap allocation from the hot path entirely. This is a fundamental HFT optimization technique.

Chapter 9 — Real World Deep Dive: EDA (Cadence, Synopsys)

TEXT

1┌───────────────────────────────────────────────────────────────┐
2│              EDA SIMULATION PIPELINE                          │
3│                                                               │
4│   RTL Source                                                  │
5│       │                                                       │
6│       ▼                                                       │
7│   LintCommand ──────────────────── Priority: HIGH             │
8│       │                                                       │
9│       ▼                                                       │
10│   CompileCommand ───────────────── Priority: HIGH             │
11│       │                                                       │
12│       ▼                                                       │
13│   ElaborateCommand ─────────────── Priority: MEDIUM           │
14│       │                                                       │
15│       ▼                                                       │
16│   SimulateCommand ──────────────── Priority: MEDIUM           │
17│   (1000 test cases, parallel)                                 │
18│       │                                                       │
19│       ▼                                                       │
20│   CoverageReportCommand ────────── Priority: LOW              │
21│       │                                                       │
22│       ▼                                                       │
23│   TimingAnalysisCommand ────────── Priority: LOW              │
24└───────────────────────────────────────────────────────────────┘
25

CPP

1// Receiver — the simulation engine
2class XceliumSimulator {
3public:
4    bool lint(const std::string& designUnit)    { /* ... */ return true; }
5    bool compile(const std::string& designUnit) { /* ... */ return true; }
6    bool simulate(const std::string& testName)  { /* ... */ return true; }
7    void rollback(const std::string& jobId)     { /* ... */ }
8};
9
10// Base command for simulation jobs
11class SimulationCommand : public Command {
12protected:
13    XceliumSimulator& sim_;
14    std::string       jobId_;
15    std::string       designUnit_;
16    bool              completed_ = false;
17
18public:
19    SimulationCommand(XceliumSimulator& sim, std::string unit)
20        : sim_(sim), designUnit_(std::move(unit)) {}
21
22    void undo() override {
23        if (completed_)
24            sim_.rollback(jobId_);
25    }
26};
27
28// Concrete simulation commands
29class LintCommand : public SimulationCommand {
30public:
31    using SimulationCommand::SimulationCommand;
32
33    void execute() override {
34        std::cout << "Linting: " << designUnit_ << "\n";
35        completed_ = sim_.lint(designUnit_);
36    }
37};
38
39class CompileCommand : public SimulationCommand {
40public:
41    using SimulationCommand::SimulationCommand;
42
43    void execute() override {
44        std::cout << "Compiling: " << designUnit_ << "\n";
45        completed_ = sim_.compile(designUnit_);
46    }
47};
48
49// EDA Job Scheduler — priority-based invoker
50struct JobEntry {
51    int                          priority;
52    std::unique_ptr<Command>     command;
53    bool operator>(const JobEntry& other) const {
54        return priority > other.priority;
55    }
56};
57
58class EDAJobScheduler {
59    std::priority_queue<
60        JobEntry,
61        std::vector<JobEntry>,
62        std::greater<JobEntry>> queue_;
63
64public:
65    void submit(int priority, std::unique_ptr<Command> cmd) {
66        queue_.push({priority, std::move(cmd)});
67        std::cout << "Job queued with priority " << priority << "\n";
68    }
69
70    void runNext() {
71        if (queue_.empty()) return;
72        auto& top = queue_.top();
73        top.command->execute();
74        queue_.pop();
75    }
76
77    void runAll() {
78        while (!queue_.empty()) runNext();
79    }
80};
81

CPP

1// Client — EDA engineer submitting jobs
2int main() {
3    XceliumSimulator xcelium;
4    EDAJobScheduler scheduler;
5
6    scheduler.submit(1, std::make_unique<LintCommand>(xcelium, "top.sv"));
7    scheduler.submit(1, std::make_unique<CompileCommand>(xcelium, "top.sv"));
8    scheduler.submit(5, std::make_unique<LintCommand>(xcelium, "tb.sv"));
9
10    scheduler.runAll();
11    // Output: runs priority 1 jobs first (lint top, compile top),
12    //         then priority 5 (lint tb)
13}
14

Chapter 10 — Real World Deep Dive: FAANG (Google Docs)

This is called Operational Transformation (OT).

TEXT

1┌──────────────────────────────────────────────────────────────┐
2│              GOOGLE DOCS CONCURRENT EDITING                  │
3│                                                              │
4│  Initial document: "Hello World"                             │
5│                                                              │
6│  User A (position 5):           User B (position 6):        │
7│  InsertCommand(" Beautiful")    DeleteCommand('W')           │
8│                                                              │
9│  Without OT:                                                 │
10│  A sees: "Hello Beautiful World"                             │
11│  B sees: "Hello orld" (W deleted, Beautiful inserted wrong)  │
12│  → DIVERGED! Documents differ!                               │
13│                                                              │
14│  With OT:                                                    │
15│  B's delete is transformed given A's insert:                 │
16│  Delete position 6 → becomes Delete position 16              │
17│  (shifted by length of " Beautiful" = 10 chars)              │
18│                                                              │
19│  Both see: "Hello Beautiful orld" → CONVERGED!               │
20└──────────────────────────────────────────────────────────────┘
21

CPP

1class InsertCommand : public Command {
2    Document&   doc_;
3    int         position_;
4    std::string text_;
5
6public:
7    InsertCommand(Document& doc, int pos, std::string text)
8        : doc_(doc), position_(pos), text_(std::move(text)) {}
9
10    void execute() override { doc_.insert(position_, text_); }
11    void undo()    override { doc_.remove(position_, text_.size()); }
12
13    // OT: transform this command given a concurrent command
14    InsertCommand transform(const InsertCommand& concurrent) const {
15        if (concurrent.position_ <= position_) {
16            // concurrent insert shifted our position right
17            return InsertCommand(doc_,
18                                 position_ + concurrent.text_.size(),
19                                 text_);
20        }
21        return *this; // our position unaffected
22    }
23
24    int position() const { return position_; }
25    int length()   const { return text_.size(); }
26};
27

Chapter 11 — Command + Thread Pool = Async Task System

The Command pattern is the backbone of every async task system. Worker threads drain a queue of Command objects:

TEXT

1┌───────────────────────────────────────────────────────────┐
2│              THREAD POOL + COMMAND QUEUE                  │
3│                                                           │
4│  Main Thread                                              │
5│      │                                                    │
6│      │── submit(CommandA) ──┐                             │
7│      │── submit(CommandB) ──┼──▶  [Command Queue]         │
8│      │── submit(CommandC) ──┘         │                   │
9│                                       │                   │
10│                              ┌────────┴────────┐          │
11│                              ▼        ▼        ▼          │
12│                           Worker1  Worker2  Worker3        │
13│                              │        │        │           │
14│                           execute  execute  execute        │
15└───────────────────────────────────────────────────────────┘
16

CPP

1#include <thread>
2#include <mutex>
3#include <condition_variable>
4#include <queue>
5#include <vector>
6#include <functional>
7
8class ThreadPool {
9    std::queue<std::unique_ptr<Command>> queue_;
10    std::mutex                          mutex_;
11    std::condition_variable             cv_;
12    std::vector<std::thread>            workers_;
13    bool                                stop_ = false;
14
15public:
16    explicit ThreadPool(int numThreads) {
17        for (int i = 0; i < numThreads; ++i) {
18            workers_.emplace_back([this] {
19                while (true) {
20                    std::unique_ptr<Command> cmd;
21                    {
22                        std::unique_lock<std::mutex> lock(mutex_);
23                        cv_.wait(lock, [this] {
24                            return !queue_.empty() || stop_;
25                        });
26                        if (stop_ && queue_.empty()) return;
27                        cmd = std::move(queue_.front());
28                        queue_.pop();
29                    }
30                    cmd->execute(); // execute outside the lock
31                }
32            });
33        }
34    }
35
36    void submit(std::unique_ptr<Command> cmd) {
37        {
38            std::lock_guard<std::mutex> lock(mutex_);
39            queue_.push(std::move(cmd));
40        }
41        cv_.notify_one();
42    }
43
44    ~ThreadPool() {
45        { std::lock_guard<std::mutex> lock(mutex_); stop_ = true; }
46        cv_.notify_all();
47        for (auto& t : workers_) t.join();
48    }
49};
50

This pattern powers:

AWS Lambda — each invocation is a command dispatched to a worker
Chrome's compositor thread — rendering commands dispatched from UI thread
Kafka consumers — each message triggers a command on a consumer thread
Database connection pools — each query is a command executed by a pool worker

Chapter 12 — Serializable Commands (Logging and Replay)

Commands that can be serialized to disk enable crash recovery, audit logs, and event replay.

TEXT

1┌──────────────────────────────────────────────────────────────┐
2│              COMMAND LOG (like a database WAL)               │
3│                                                              │
4│  Timestamp        Command            Data                    │
5│  ─────────────────────────────────────────────────────────   │
6│  1714000000001    PLACE_ORDER        AAPL|100|150.00|B       │
7│  1714000000042    PLACE_ORDER        MSFT|50|300.00|S        │
8│  1714000000199    CANCEL_ORDER       ordId:XYZ123            │
9│  1714000000341    MODIFY_ORDER       ordId:ABC456|qty:75      │
10│                                                              │
11│  On crash recovery:                                          │
12│  1. Read log from disk                                       │
13│  2. Deserialize each line into a Command object              │
14│  3. Re-execute each command                                  │
15│  4. System state restored!                                   │
16└──────────────────────────────────────────────────────────────┘
17

CPP

1class SerializableCommand : public Command {
2public:
3    virtual std::string serialize()               const = 0;
4    virtual void        deserialize(const std::string&)  = 0;
5    virtual std::string commandType()             const = 0;
6};
7
8// Command registry — maps type name to factory function
9class CommandRegistry {
10    using Factory = std::function<std::unique_ptr<SerializableCommand>()>;
11    std::unordered_map<std::string, Factory> registry_;
12
13public:
14    void registerCommand(const std::string& type, Factory factory) {
15        registry_[type] = std::move(factory);
16    }
17
18    std::unique_ptr<SerializableCommand> create(const std::string& type) {
19        auto it = registry_.find(type);
20        if (it == registry_.end())
21            throw std::runtime_error("Unknown command: " + type);
22        return it->second();
23    }
24};
25
26// Command logger — writes to disk on every execute
27class CommandLogger {
28    std::ofstream   log_;
29    CommandInvoker& invoker_;
30
31public:
32    CommandLogger(const std::string& logPath, CommandInvoker& invoker)
33        : log_(logPath, std::ios::app), invoker_(invoker) {}
34
35    void execute(std::unique_ptr<SerializableCommand> cmd) {
36        cmd->execute();
37        // Write to audit log
38        log_ << cmd->commandType() << "|" << cmd->serialize() << "\n";
39        log_.flush(); // ensure durability
40    }
41};
42

Chapter 13 — Command vs Strategy — The Confusion Cleared

These two patterns are often confused. Let us clear this up once and for all.

TEXT

1┌─────────────────────────────────────────────────────────────┐
2│                COMMAND vs STRATEGY                          │
3│                                                             │
4│   COMMAND                      STRATEGY                     │
5│   ─────────────────────────    ────────────────────────     │
6│   Encapsulates a REQUEST       Encapsulates an ALGORITHM    │
7│   "Do this thing"              "Do this thing THIS way"     │
8│                                                             │
9│   Has execute() + undo()       Has execute() only           │
10│                                                             │
11│   Stores STATE (what was       Stateless (just the algo)    │
12│   done, for undo)                                           │
13│                                                             │
14│   Used for: undo/redo,         Used for: swap sort algo,    │
15│   queuing, logging, replay     swap compression, swap route  │
16│                                                             │
17│   Example:                     Example:                     │
18│   BoldCommand — applies bold   BubbleSort — sorts a list    │
19│   can be undone, logged,       cannot be "undone",          │
20│   queued, replayed             just a different way to sort  │
21└─────────────────────────────────────────────────────────────┘
22

CPP

1// Strategy — swappable algorithm, no state, no undo
2class SortStrategy {
3public:
4    virtual void sort(std::vector<int>& data) = 0;
5};
6
7class BubbleSort : public SortStrategy {
8public:
9    void sort(std::vector<int>& data) override { /* bubble sort */ }
10};
11
12// Command — encapsulates a request with undo
13class SortCommand : public Command {
14    std::vector<int>&               data_;
15    std::unique_ptr<SortStrategy>   strategy_;
16    std::vector<int>                backup_; // for undo!
17public:
18    SortCommand(std::vector<int>& data, std::unique_ptr<SortStrategy> s)
19        : data_(data), strategy_(std::move(s)) {}
20
21    void execute() override {
22        backup_ = data_;           // save for undo
23        strategy_->sort(data_);    // use strategy to do the work
24    }
25
26    void undo() override {
27        data_ = backup_;           // restore original order
28    }
29};
30

See the relationship? A Command can use a Strategy internally. They are not competitors — they are collaborators.

Chapter 14 — When to Use, When to Avoid

TEXT

1┌─────────────────────────────────────────────────────────────┐
2│                    DECISION GUIDE                           │
3│                                                             │
4│   USE Command when you need:                                │
5│   ✅ Undo / Redo                                            │
6│   ✅ Queue operations for later execution                   │
7│   ✅ Log or audit operations                                │
8│   ✅ Replay operations                                      │
9│   ✅ Macro / batch operations                               │
10│   ✅ Transactional behavior (execute + rollback)            │
11│   ✅ Decouple UI from business logic                        │
12│   ✅ Remote execution (send command object over network)    │
13│                                                             │
14│   AVOID Command when:                                       │
15│   ❌ Operations are simple, one-directional, no undo needed │
16│   ❌ One invoker, never changes, no queuing needed          │
17│   ❌ Adding a class per operation is overkill               │
18│   ❌ Performance-critical path where virtual calls hurt     │
19│      (consider std::function or templates instead)          │
20└─────────────────────────────────────────────────────────────┘
21

Chapter 15 — Modern C++ Shortcut: Lambda as Command

In modern C++ (C++11 and beyond), simple commands can be expressed as lambdas stored in std::function — no class needed:

CPP

1using CommandFn = std::pair<
2    std::function<void()>,   // execute
3    std::function<void()>    // undo
4>;
5
6class LambdaInvoker {
7    std::stack<CommandFn> history_;
8public:
9    void execute(CommandFn cmd) {
10        cmd.first();             // call execute
11        history_.push(cmd);
12    }
13    void undo() {
14        if (history_.empty()) return;
15        history_.top().second(); // call undo
16        history_.pop();
17    }
18};
19
20// Usage — no class needed for simple cases
21TextEditor editor;
22LambdaInvoker invoker;
23
24invoker.execute({
25    [&editor] { editor.bold(); },          // execute
26    [&editor] { editor.removeLast(6); }    // undo
27});
28

When to use classes vs lambdas:

Chapter 16 — Complete Architecture Diagram

TEXT

1┌─────────────────────────────────────────────────────────────────────┐
2│                   COMMAND PATTERN — FULL ARCHITECTURE               │
3│                                                                     │
4│                          ┌───────────┐                              │
5│                          │  Client   │                              │
6│                          └─────┬─────┘                              │
7│                                │ creates & wires                    │
8│              ┌─────────────────┼──────────────────┐                 │
9│              │                 │                  │                 │
10│              ▼                 ▼                  ▼                 │
11│        ┌──────────┐    ┌──────────────┐    ┌──────────┐            │
12│        │ Receiver │    │   Invoker    │    │ Command  │            │
13│        │          │    │              │    │Interface │            │
14│        │ TextEditor    │ + execute()  │    │          │            │
15│        │ OMS      │    │ + undo()     │    │+execute()│            │
16│        │ Simulator│    │ + history_   │    │+undo()   │            │
17│        └────┬─────┘    └──────┬───────┘    └────┬─────┘            │
18│             │                 │                 │ implements        │
19│             │                 │     ┌───────────┼───────────┐       │
20│             │                 │     │           │           │       │
21│             │                 │     ▼           ▼           ▼       │
22│             │                 │  BoldCmd  ItalicCmd  MacroCmd       │
23│             │                 │     │           │           │       │
24│             └─────────────────┴─────┴───────────┘           │       │
25│                    delegates work to receiver                │       │
26│                                                             │       │
27│                    MacroCmd contains other Commands ────────┘       │
28└─────────────────────────────────────────────────────────────────────┘
29

Chapter 17 — Summary: The Five Powers of Command

TEXT

1┌─────────────────────────────────────────────────────────────────┐
2│              THE FIVE POWERS OF COMMAND PATTERN                 │
3│                                                                 │
4│  1. UNDO / REDO                                                 │
5│     Every command knows how to reverse itself.                  │
6│     Stack gives you full history. Free redo with two stacks.    │
7│                                                                 │
8│  2. QUEUEING                                                    │
9│     Commands are objects — store them, defer them,              │
10│     drain them at your pace. Thread pool = free async.          │
11│                                                                 │
12│  3. LOGGING                                                     │
13│     Serialize command objects to disk. Audit trail for free.    │
14│     Replay from log = crash recovery for free.                  │
15│                                                                 │
16│  4. MACRO / COMPOSITION                                         │
17│     MacroCommand groups commands. Execute as one.               │
18│     Undo as one. Photoshop Actions. Smart home scenes.          │
19│                                                                 │
20│  5. DECOUPLING                                                  │
21│     Invoker knows nothing about Receiver.                       │
22│     Add new commands: zero invoker changes.                     │
23│     Add new invokers: zero command changes.                     │
24└─────────────────────────────────────────────────────────────────┘
25

Chapter 18 — Practice Exercises (Levelled)

Level 1 — Calculator with Undo

Implement a calculator supporting Add, Subtract, Multiply, Divide commands with a full undo/redo stack.

Requirements:

Each operation is a Command
undo() reverses the operation mathematically (add 5 → undo subtracts 5)
Full undo/redo history

Starter:

CPP

1class Calculator {
2    double value_ = 0;
3public:
4    void add(double n)      { value_ += n; }
5    void subtract(double n) { value_ -= n; }
6    void multiply(double n) { value_ *= n; }
7    void divide(double n)   { if (n != 0) value_ /= n; }
8    double value() const    { return value_; }
9};
10
11// Your task: implement AddCommand, SubtractCommand,
12// MultiplyCommand, DivideCommand
13// Wire them to a CommandInvoker with undo/redo
14

Level 2 — Smart Home Controller

Build a smart home system with:

LightOnCommand / LightOffCommand
ThermostatSetCommand
LockDoorCommand / UnlockDoorCommand
A "Goodnight" MacroCommand that: turns off all lights, sets thermostat to 18°C, locks the door

Bonus: A "Morning" MacroCommand that reverses the Goodnight macro.

Level 3 — Simplified Git

Implement a versioned file system:

CommitCommand — saves a snapshot of current files
RevertCommand — restores a previous commit
BranchCommand — creates a named branch (fork of history)

Hint: Use the Memento pattern for snapshots.

Level 4 — HFT Order Book (Advanced)

Build a simplified trading command system:

PlaceOrderCommand with pre-allocated memory pool (no heap in hot path)
CancelOrderCommand
A lock-free SPSC ring buffer as the command queue
rdtsc-based latency measurement — measure time from submit to execute
Serialize every command to a log file for audit

Level 5 — Distributed Command Log

Build a command log that:

Serializes commands to disk on every execute
On startup, reads the log and replays all commands to restore state
Supports "time travel" — replay up to a given timestamp

This is how databases implement crash recovery (WAL — Write-Ahead Log).

Final Words

The Command pattern is one of those patterns you will use everywhere once you see it. Every undo stack, every job queue, every audit log, every macro system — it is Command under the hood.

That is what understanding patterns gives you — X-ray vision into the systems around you.

What to do next:

Implement Level 1 without looking at the solution

Read the source code of an open-source editor (VSCode, Vim) and find their command/action system

Look at how Kafka consumer offsets work — it is Command + log at scale

Come back and attempt Level 4 after you have read about lock-free data structures