What is the Command pattern?

Question

Accepted Answer

The **Command** pattern encapsulates a **request as an object** — turning an action into a standalone object with all its information. This enables queuing, logging, undo/redo, and decoupling the requester from the executor.

## What the Command pattern does

```text
COMMAND → encapsulate an action/request as an OBJECT (with its data and an execute method):
  → a command object knows WHAT to do and has the info to do it
  → the invoker triggers commands without knowing their details
  → decouples the object that INVOKES from the object that PERFORMS the action
→ "turn an action into an object" → store, pass, queue, log, undo it
```

## Example

```js
// commands encapsulate actions
class AddTextCommand {
  constructor(doc, text) { this.doc = doc; this.text = text; }
  execute() { this.doc.add(this.text); }
  undo() { this.doc.remove(this.text); }   // commands can support undo
}
// invoker executes and tracks commands (for undo/redo)
const cmd = new AddTextCommand(doc, 'hello');
cmd.execute();
cmd.undo();   // reverse it
```

## What it enables

```text
✓ UNDO/REDO → store executed commands; call undo()/redo() (each command knows how to reverse)
✓ QUEUING → queue commands to execute later; schedule; batch
✓ LOGGING → log commands (e.g. for replay, audit, transactions)
✓ DECOUPLING → invoker doesn't know the command's implementation (just calls execute())
USES → undo/redo (editors), task queues/jobs, transactional operations, action objects
  (e.g. Redux actions), macro recording, GUI buttons/menu items triggering commands
```

## Why it matters

Understanding the Command pattern is valuable because it's a **useful behavioral pattern** that enables important capabilities like undo/redo and queuing, so it's relevant design knowledge.

The Command pattern encapsulates a request as an object — turning an action into a standalone object with its data and an execute method, decoupling the requester from the executor.

Understanding what it does (representing an action as an object that knows what to do, with the invoker triggering commands without knowing their details) is the core knowledge.

Understanding **what it enables** is the key value: **undo/redo** (storing executed commands and calling undo/redo, with each command knowing how to reverse itself — the classic, powerful use case for editors and applications), **queuing** (queuing commands to execute later, schedule, or batch), **logging** (logging commands for replay, audit, or transactions), and **decoupling** (the invoker not knowing the command's implementation).

These capabilities — especially undo/redo and queuing — are genuinely valuable and hard to implement cleanly without the Command pattern.

Understanding the **uses** — undo/redo in editors, task queues and background jobs, transactional operations, action objects (like Redux actions, a widely-used modern example), macro recording, and GUI elements triggering commands — clarifies its real-world applicability.

The Command pattern is the clean way to implement undo/redo, queuing, and action-based architectures.

Since the Command pattern enables important capabilities (undo/redo, queuing, logging, decoupling) that are valuable and hard to implement cleanly otherwise, and since it appears in real systems (editors, task queues, Redux actions), and since understanding what it does and enables is relevant for implementing these capabilities, understanding the Command pattern is valuable, practically-relevant design knowledge — a useful pattern enabling undo/redo, queuing, and action-based architectures (like Redux actions), the clean way to implement these valuable capabilities, and important design knowledge for actions that need to be stored, queued, logged, or undone.