Command pattern for undo in LLD - Deep Dive

Overview - Command pattern for undo

What is it?

The Command pattern for undo is a design approach that lets you record actions as objects. Each action knows how to do itself and how to undo itself. This helps programs reverse changes step-by-step, like pressing Ctrl+Z in a text editor. It separates the action logic from the place where actions are triggered.

Why it matters

Without this pattern, undoing actions would be messy and error-prone because the program would need to remember and reverse every change manually. This pattern makes undo reliable and easy to manage, improving user experience and reducing bugs. It also allows flexible command management, like redoing or batching actions.

Where it fits

Before learning this, you should understand basic object-oriented design and how to encapsulate behavior in objects. After this, you can explore more complex patterns like Memento for state saving or Event Sourcing for full history tracking.

Mental Model

Core Idea

Each user action is wrapped as a command object that knows how to execute and undo itself, enabling easy reversal of operations.

Think of it like...

Imagine writing with a pencil and keeping a list of every stroke you make. If you want to erase the last stroke, you just look at the last item on your list and undo it. Each stroke knows how to erase itself.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Client      │──────▶│  Command      │──────▶│  Receiver     │
│ (Invoker)     │       │ (Action + Undo)│       │ (Does work)   │
└───────────────┘       └───────────────┘       └───────────────┘
        ▲                      │                        ▲
        │                      │                        │
        │                      ▼                        │
        │               ┌───────────────┐              │
        │               │ Undo Stack    │◀─────────────┘
        │               │ (Stores cmds) │
        │               └───────────────┘

Build-Up - 7 Steps

1

Foundation

Understanding Commands as Objects

Concept: Commands encapsulate all information needed to perform an action.

A command object holds the details of an action, like what to do and on which object. For example, a 'DrawLine' command knows how to draw a line on a canvas. This separates the action from the user interface or caller.

Result

You can create, store, and pass around commands independently of how they are executed.

Understanding commands as objects is key because it turns actions into manageable units that can be stored and manipulated.

2

Foundation

Basic Undo Concept

Concept: Each command also knows how to undo itself.

Besides doing the action, commands implement an undo method that reverses the effect. For example, 'DrawLine' can erase the line it drew. This dual behavior is essential for undo functionality.

Result

You can reverse any command by calling its undo method.

Knowing that commands carry their own undo logic simplifies reversing actions without external state tracking.

3

Intermediate

Managing Undo with a Stack

🤔Before reading on: do you think undo commands should be stored in a queue or a stack? Commit to your answer.

Concept: Undo commands are stored in a stack to reverse actions in the correct order.

When a command executes, it is pushed onto an undo stack. Undoing means popping the last command and calling its undo method. This LIFO (last-in, first-out) order matches user expectations for undo.

Result

Undo operations happen in reverse order of execution, correctly reverting changes step-by-step.

Understanding the stack structure is crucial because it naturally models the undo sequence users expect.

4

Intermediate

Decoupling Invoker and Receiver

🤔Before reading on: do you think the invoker should know how to perform the action or just call the command? Commit to your answer.

Concept: The invoker triggers commands without knowing their details; receivers perform the actual work.

The invoker holds commands and calls execute or undo on them. The receiver is the object that actually changes state, like a document or a drawing canvas. This separation allows flexible command reuse and testing.

Result

Commands can be reused or extended without changing the invoker or receiver.

Decoupling improves modularity and makes the system easier to maintain and extend.

5

Intermediate

Implementing Redo Functionality

🤔Before reading on: do you think redo can be done without storing undone commands? Commit to your answer.

Concept: Redo requires a separate stack to store undone commands for re-execution.

When undo is called, the command is popped from the undo stack and pushed onto a redo stack. Redo pops from the redo stack and executes the command again, pushing it back to undo stack. This cycle allows toggling between undo and redo.

Result

Users can move backward and forward through their action history.

Knowing redo needs its own stack prevents common bugs where redo is impossible after undo.

6

Advanced

Handling Complex Commands and Batching

🤔Before reading on: do you think a single command can represent multiple actions? Commit to your answer.

Concept: Commands can be composed to represent multiple actions as one undoable unit.

A composite command groups several commands and executes or undoes them together. This is useful for complex operations like formatting a paragraph or moving multiple objects. It ensures undo treats them as a single step.

Result

Undo and redo work seamlessly for grouped actions, improving user experience.

Understanding command composition allows building flexible and user-friendly undo systems.

7

Expert

Optimizing Undo with State Snapshots

🤔Before reading on: do you think storing full state snapshots is always better than command-based undo? Commit to your answer.

Concept: Sometimes commands store state snapshots to simplify undo, trading memory for simplicity.

Instead of reversing actions, commands can save the state before execution and restore it on undo. This is simpler but uses more memory. Hybrid approaches combine snapshots and command logic for efficiency.

Result

Undo becomes more reliable for complex or non-reversible actions but requires careful memory management.

Knowing when to use snapshots versus pure command undo helps balance performance and complexity in real systems.

Under the Hood

Each command object implements two methods: execute and undo. When execute is called, the command performs its action on the receiver. The command is then pushed onto an undo stack. Undo pops the last command and calls its undo method, reversing the action. Redo uses a separate stack to reapply undone commands. Commands may store necessary state to undo correctly. The invoker only calls execute or undo without knowing command internals.

Why designed this way?

This pattern was designed to separate concerns: the invoker triggers actions, commands encapsulate behavior, and receivers perform work. This separation allows flexible command management, easy undo/redo, and decouples UI from business logic. Alternatives like direct state manipulation were error-prone and hard to maintain. The stack structure matches natural user expectations for undo order.

┌───────────────┐       ┌───────────────┐       ┌───────────────┐
│   Invoker     │──────▶│   Command     │──────▶│   Receiver    │
│ (Client/UI)   │       │ (execute/undo)│       │ (performs act)│
└───────────────┘       └───────────────┘       └───────────────┘
        │                      │                        ▲
        │                      │                        │
        │                      ▼                        │
        │               ┌───────────────┐              │
        │               │ Undo Stack    │◀─────────────┘
        │               └───────────────┘
        │                      │
        │                      ▼
        │               ┌───────────────┐
        │               │ Redo Stack    │
        │               └───────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Does undo always mean reversing the exact last command? Commit to yes or no.

Common Belief: Undo simply reverses the last command exactly as it was executed.

Reality: Undo may require additional state or logic because some commands are not perfectly reversible by just running the opposite action.

Why it matters: Assuming undo is always a simple reverse leads to bugs where undo fails or corrupts state, especially with complex or external effects.

Quick: Is it okay to store all commands forever for undo? Commit to yes or no.

Common Belief: You can keep every command in memory indefinitely to allow unlimited undo.

Reality: Storing all commands can consume too much memory; practical systems limit undo history or use snapshots to manage resources.

Why it matters: Ignoring resource limits causes performance issues or crashes in real applications.

Quick: Can redo be done without a separate redo stack? Commit to yes or no.

Common Belief: Redo can be implemented by re-executing commands from the undo stack.

Reality: Redo requires a separate redo stack because undo removes commands from the undo stack; without it, redo is impossible.

Why it matters: Misunderstanding redo storage leads to broken redo functionality and poor user experience.

Quick: Does the invoker need to know how commands work internally? Commit to yes or no.

Common Belief: The invoker must understand command details to execute or undo them properly.

Reality: The invoker only calls execute or undo methods; command internals are hidden, enabling loose coupling.

Why it matters: Mixing invoker and command logic reduces modularity and makes maintenance harder.

Expert Zone

1

Commands sometimes need to store pre-execution state snapshots to undo non-reversible actions safely.

2

Composite commands enable grouping multiple actions into a single undoable step, improving user experience.

3

Undo stacks often have size limits and pruning strategies to balance memory use and functionality.

When NOT to use

Avoid using the command pattern for undo when actions are simple and stateless, or when full state snapshots (Memento pattern) are more efficient. For distributed systems, event sourcing or version control may be better alternatives.

Production Patterns

In real systems, undo commands are often serialized for persistence, allowing undo after restarts. Systems use command queues with transactional guarantees to ensure consistency. UI frameworks integrate command pattern with keyboard shortcuts and menus for seamless user control.

Connections

Memento pattern

Complementary pattern

Understanding command pattern helps grasp how Memento stores object states for undo, showing two ways to implement undo functionality.

Event sourcing

Builds on command history

Event sourcing records all changes as events (commands), enabling full history replay and undo, extending the command pattern to distributed systems.

Legal contract revocation

Similar concept in law

Undoing a command is like legally revoking a contract: both require a clear record of the original action and a defined way to reverse it, showing cross-domain parallels.

Common Pitfalls

#1 Not storing enough state to undo complex commands

Wrong approach:

class DeleteTextCommand {
execute() { document.deleteText(); }
undo() { document.insertText(); } // no stored text
}

Correct approach:

class DeleteTextCommand {
constructor(text) { this.text = text; }
execute() { document.deleteText(); }
undo() { document.insertText(this.text); }
}

Root cause:

Assuming undo can recreate state without saving necessary data leads to incomplete or broken undo.

#2 Using a queue instead of a stack for undo storage

Wrong approach:

undoQueue.enqueue(command);
command = undoQueue.dequeue();
command.undo();

Correct approach:

undoStack.push(command);
command = undoStack.pop();
command.undo();

Root cause:

Misunderstanding undo order causes commands to be undone in the wrong sequence.

#3 Clearing redo stack incorrectly after new command

Wrong approach:

undoStack.push(newCommand);
// forgot to clear redoStack

Correct approach:

undoStack.push(newCommand);
redoStack.clear();

Root cause:

Not clearing redo stack after new actions breaks redo history and confuses users.

Key Takeaways

The command pattern encapsulates actions and their undo logic into objects, enabling flexible undo and redo.

Undo operations use a stack to reverse actions in the correct order, matching user expectations.

Decoupling the invoker, command, and receiver improves modularity and maintainability.

Redo requires a separate stack to store undone commands for re-execution.

Advanced undo systems use composite commands and state snapshots to handle complex scenarios efficiently.