Command

The four players

The pattern splits 'a button press turns on a light' into four small roles. The split looks like ceremony at first, but each role is what unlocks one of the pattern's powers:

• Command interface — the tiny contract every action signs: execute() and (for undoable systems) undo(). This is all the invoker ever sees.
• Concrete commands — one small class per action: LightOnCommand, LightOffCommand, ThermostatUpCommand. Each one holds a reference to its receiver and knows how to perform and reverse exactly one request.
• Receiver — the object that does the real work: the Light, the Thermostat. It has ordinary methods (turnOn(), up()) and knows nothing about commands at all.
• Invoker — the remote button (or menu item, or job queue worker). It holds some command and calls execute() on it. It never knows the concrete class — swap which command a button holds and the button's behaviour changes without touching the button.

The client (your setup code) wires it all together: it creates the receivers, creates concrete commands around them, and hands those commands to the invoker. Notice how this echoes [[dependency-injection-and-ioc]] — the button is given its behaviour from outside rather than hard-coding it.

How undo works

Each command knows how to reverse itself: LightOnCommand.undo() turns the light back off; ThermostatUpCommand.undo() steps the temperature back down. The invoker keeps a history stack — every executed command gets pushed on top. Undo pops the most recent command and calls its undo(), which unwinds actions in exact reverse order. Redo, if you want it, is a second stack of undone commands. Real systems cap the stack (say, the last 100 actions), so the oldest commands eventually fall off and can no longer be undone — the prototype's 6-slot stack shows this honestly.

interface Command {
  execute(): void;
  undo(): void;
}

class LightOnCommand implements Command {
  constructor(private light: Light) {}   // wraps action + receiver
  execute() { this.light.turnOn(); }
  undo()    { this.light.turnOff(); }    // knows its own reverse
}

class RemoteButton {                     // invoker
  private history: Command[] = [];
  press(cmd: Command) {
    cmd.execute();                       // run the request...
    this.history.push(cmd);              // ...and remember it
  }
  undo() {
    this.history.pop()?.undo();          // reverse the latest one
  }
}

Look at what RemoteButton doesn't know: no if (button === 'light') branching, no reference to Light or Thermostat, no knowledge of what any command does. It just tells the command to execute — a clean example of [[tell-dont-ask]] at the object level. All the device-specific knowledge lives inside the concrete commands.

You've already met this pattern

• Editor undo/redo — every keystroke, deletion, and format change is a command on a stack; Ctrl+Z pops and reverses it.
• Job and task queues — a background job is a serialized command: created now, queued, executed later by a worker that only knows the run() interface.
• Transactional operations — each step of a multi-step operation is a command with a compensating undo(), so a failure can roll everything back in reverse.
• GUI buttons and menu items — 'Copy' in the toolbar, the Edit menu, and Ctrl+C all hold the same command object; one action, three invokers.
• Macro recording — record the commands a user performs into a list, then replay the list to repeat the whole sequence.

Reach for Command when the request itself needs a life of its own

The tell-tale sign is that you need to do something with an action besides just running it right now:

• Undo / redo — the flagship use. Keep executed commands on a stack; each knows how to reverse itself, so Ctrl+Z is a pop and an undo().
• Queues and scheduling — create a request now, run it later (or elsewhere). Background jobs, thread pools, and task schedulers all pass command-shaped objects to workers that only know run().
• Decoupling the trigger from the action — toolbar button, menu item, and keyboard shortcut all hold the same command object; UI elements become interchangeable holders of behaviour instead of hard-coding it.
• Macros, logging, and replay — a list of commands is a recording. Replay it for macros, write it to disk as an audit log, or re-run it to recover state after a crash.