Command Pattern

Encapsulate requests as objects - queue, log, and undo operations with full control!

Command Pattern: Turning Requests into Objects

Now let’s dive into the Command Pattern - one of the most versatile behavioral design patterns that encapsulates a request as an object, letting you parameterize clients with different requests, queue operations, log them, and support undoable operations.

Why Command Pattern?

Imagine you’re using a text editor. You type some text, then click Undo - the text disappears. Click Redo - it comes back. How does this work? The Command Pattern! Each action (typing, deleting, formatting) is wrapped in a command object that knows how to execute itself AND how to undo itself.

The Command Pattern turns requests into stand-alone objects containing all information about the request. This transformation lets you pass requests as method arguments, delay or queue a request’s execution, and support undoable operations.

What’s the Use of Command Pattern?

The Command Pattern is useful when:

You need undo/redo functionality - Commands can be reversed
You want to queue operations - Execute commands later or in sequence
You need to log operations - Commands can be serialized and logged
You want to decouple sender from receiver - Invoker doesn’t know about receiver
You need transactional behavior - Rollback if something fails

What Happens If We Don’t Use Command Pattern?

Without the Command Pattern, you might:

Tight coupling - Invoker directly calls receiver methods
No undo support - Have to manually track all changes
Hard to queue operations - Operations execute immediately
No operation logging - Can’t track what was done
Scattered code - Same operation code repeated everywhere

Simple Example: The Remote Control

Let’s start with a super simple example that anyone can understand!

Visual Representation

Interaction Flow

Here’s how the Command Pattern works in practice - showing how commands are executed and undone:

The Problem

You’re building a smart home system with a remote control. The remote needs to control different devices (lights, fans, TVs). Without Command Pattern:

Problems:

Remote control is tightly coupled to all device types
Adding new devices requires modifying RemoteControl
No undo functionality - can’t reverse actions
No way to queue or log commands

The Solution: Command Pattern

Class Structure

Real-World Software Example: Text Editor with Undo/Redo

Now let’s see a realistic software example - a text editor that supports full undo/redo functionality.

The Problem

You’re building a text editor that needs to support multiple operations (typing, deleting, formatting) with full undo/redo capability. Without Command Pattern:

Problems:

Complex undo tracking for each operation type
Need to modify editor for each new operation
History management is complex and error-prone
No redo support
Hard to serialize/log operations

The Solution: Command Pattern

Class Structure

Command Pattern Variants

There are different ways to implement the Command Pattern:

1. Simple Command (No Undo)

When undo isn’t needed:

Pros: Simple, lightweight
Cons: No undo support

2. Command with Callback

Using callbacks for results:

Pros: Supports async operations
Cons: More complex

3. Command Queue

Queuing commands for batch execution:

When to Use Command Pattern?

Use Command Pattern when:

✅ You need undo/redo - Commands know how to reverse themselves
✅ You want to queue operations - Execute later or in sequence
✅ You need operation logging - Commands can be serialized and logged
✅ You want to decouple - Invoker doesn’t know about receiver
✅ You need transactional behavior - Rollback if something fails

When NOT to Use Command Pattern?

Don’t use Command Pattern when:

❌ Simple operations - Direct method calls are clearer
❌ No undo needed - Overhead isn’t justified
❌ No operation history - Don’t need logging or auditing
❌ Performance critical - Command objects add overhead
❌ Over-engineering - Don’t add complexity for simple cases

Common Mistakes to Avoid

Mistake 1: Commands That Don’t Store State for Undo

Mistake 2: Commands That Modify External State

Mistake 3: Not Clearing Redo Stack on New Command

Benefits of Command Pattern

Decoupling - Invoker doesn’t know about receiver
Undo/Redo - Commands know how to reverse themselves
Queueing - Commands can be queued for later execution
Logging - Commands can be serialized and logged
Transactions - Group commands for atomic execution
Macro Commands - Combine multiple commands into one

Revision: Quick Catch-Up

What is Command Pattern?

Command Pattern is a behavioral design pattern that turns a request into a stand-alone object containing all information about the request. This lets you parameterize methods with different requests, delay or queue a request’s execution, and support undoable operations.

Why Use It?

✅ Undo/Redo - Commands know how to reverse
✅ Queueing - Execute commands later
✅ Logging - Track all operations
✅ Decoupling - Invoker doesn’t know receiver
✅ Macro commands - Combine operations

How It Works?

Define Command interface - execute() and undo() methods
Create Concrete Commands - Each wraps a receiver action
Create Receiver - The object that performs the action
Create Invoker - Triggers commands, manages history
Client - Creates commands and configures invoker

Key Components

1
Client → creates → Command → calls → Receiver
2
       ↓
3
    Invoker → invokes → Command

Command - Interface with execute() and undo()
Concrete Command - Wraps receiver and action
Receiver - Performs the actual work
Invoker - Triggers commands, stores history
Client - Creates and configures commands

Simple Example

When to Use?

✅ Need undo/redo functionality
✅ Need to queue operations
✅ Need to log all operations
✅ Need to decouple invoker from receiver
✅ Need transactional behavior

When NOT to Use?

❌ Simple operations
❌ No undo needed
❌ No operation history needed
❌ Over-engineering simple cases

Key Takeaways

Command Pattern = Operations as objects
Command = Encapsulates action and undo
Invoker = Triggers commands, manages history
Receiver = Performs actual work
Benefit = Undo, queueing, logging, decoupling

Common Pattern Structure

Remember

Command Pattern encapsulates operations as objects
It enables undo/redo by storing state
It supports queueing and logging operations
Use it when you need operation history
Don’t use it for simple direct calls!

Interview Focus: Command Pattern

Key Points to Remember

1. Core Concept

What to say:

“Command Pattern is a behavioral design pattern that encapsulates a request as an object. This allows you to parameterize clients with different requests, queue operations, log them, and support undoable operations. The command object contains all information needed to perform an action.”

Why it matters:

Shows you understand the fundamental purpose
Demonstrates knowledge of encapsulation
Indicates you can explain concepts clearly

2. When to Use Command Pattern

Must mention:

✅ Undo/Redo - Each command knows how to reverse itself
✅ Operation queueing - Execute later or in batch
✅ Logging/Auditing - Commands can be serialized
✅ Decoupling - Invoker doesn’t know about receiver
✅ Transactional behavior - Rollback on failure

Example scenario to give:

“I’d use Command Pattern when building a text editor. Each operation - typing, deleting, formatting - is a command object. This makes undo/redo trivial: just pop from undo stack, call undo(), push to redo stack. We can also log all commands for crash recovery or collaboration features.”

3. Command vs Strategy Pattern

Must discuss:

Command - Encapsulates an operation with its state, supports undo
Strategy - Encapsulates an algorithm, algorithms are interchangeable
Key difference - Command has state and undo, Strategy is stateless

Example to give:

“Command Pattern encapsulates an operation - ‘delete text at position 5’ - and knows how to undo it. Strategy Pattern encapsulates an algorithm - ‘sort using QuickSort’ - but doesn’t track state. Commands remember what they did so they can undo it; strategies just execute algorithms.”

4. Implementing Undo/Redo

Must explain:

Undo Stack - Stores executed commands
Redo Stack - Stores undone commands
Execute - Execute command, push to undo stack, clear redo stack
Undo - Pop from undo, call undo(), push to redo
Redo - Pop from redo, call execute(), push to undo

Code to have ready:

1
class Editor:
2
    def __init__(self):
3
        self.undo_stack = []
4
        self.redo_stack = []
5

6
    def execute(self, command):
7
        command.execute()
8
        self.undo_stack.append(command)
9
        self.redo_stack.clear()  # Important!
10

11
    def undo(self):
12
        if self.undo_stack:
13
            cmd = self.undo_stack.pop()
14
            cmd.undo()
15
            self.redo_stack.append(cmd)
16

17
    def redo(self):
18
        if self.redo_stack:
19
            cmd = self.redo_stack.pop()
20
            cmd.execute()
21
            self.undo_stack.append(cmd)

5. Benefits and Trade-offs

Benefits to mention:

Decoupling - Invoker doesn’t know about receiver
Undo/Redo - Commands are reversible
Queueing - Commands can be queued
Logging - Commands can be serialized
Macro Commands - Combine multiple commands

Trade-offs to acknowledge:

Complexity - More classes than direct calls
Memory - Commands store state for undo
Overhead - Command objects have cost
Overkill for simple cases - Direct calls are simpler

6. Common Interview Questions

Q: “How would you implement undo in a text editor?”

“I’d use Command Pattern. Each operation - TypeCommand, DeleteCommand, FormatCommand - stores the state needed to undo itself. DeleteCommand stores the deleted text. When execute() is called, it deletes and stores what was deleted. When undo() is called, it restores the deleted text. The editor maintains undo/redo stacks to track command history.”

Q: “How does Command Pattern support transactions?”

“You can create a TransactionCommand that holds multiple commands. On execute(), it executes all commands in sequence. If any fails, it calls undo() on all previously executed commands in reverse order. This gives atomic, all-or-nothing behavior - either all commands succeed or all are rolled back.”

Q: “How does Command Pattern relate to SOLID principles?”

“Command Pattern supports Single Responsibility - each command handles one operation. It supports Open/Closed - add new commands without modifying invoker. It supports Dependency Inversion - invoker depends on Command interface, not concrete commands. It also supports Interface Segregation - Command interface is focused (execute, undo).”

Interview Checklist

Before your interview, make sure you can:

Remember: Command Pattern is about encapsulating operations as objects - enabling undo, queueing, and logging with full control over execution! 🎮

Request a feature or report an issue