Command Pattern Implementor

⚡ When to Use

💡 Examples

Example 1: Document Editor with Multi-Level Undo

Scenario: A text editor with menus for Cut, Copy, Paste, and Bold. Users expect unlimited undo/redo accessible from Edit > Undo and Edit > Redo, and from Ctrl+Z / Ctrl+Y. The same Cut command should be triggerable from the menu, the toolbar, and the keyboard shortcut.

Trigger: "We need multi-level undo for edit operations and the same command needs to work from three different places in the UI."

Process:

Step 1: Invoker = MenuItem + ToolbarButton + KeyboardHandler. Receiver = Document. Client = Application.

Step 2: Full undo protocol — Command interface includes Execute, Unexecute, Reversible.

Step 3: CutCommand captures the cut selection and clipboard content at Execute time. BoldCommand captures the affected range and original font at Execute time.

Step 4: CommandHistory with present-line pointer. Edit > Undo calls history.Undo(). Edit > Redo calls history.Redo().

Step 6: Application creates one CutCommand(document), assigns it to the menu item, toolbar button, and keyboard handler. All three share the same instance.

Output:

CutCommand.Execute() saves selected text to clipboard, deletes from document, records deleted range + content

CutCommand.Unexecute() re-inserts recorded content at recorded range, updates clipboard

History state after three edits: [CutCmd | BoldCmd | PasteCmd] | (present at end)

After two undos: [CutCmd | BoldCmd | PasteCmd] (present points at CutCmd)

After typing a new character: [CutCmd | TypeCmd] (BoldCmd and PasteCmd discarded)

---

Example 2: Database Transaction System

Scenario: A database management system needs to support atomic transactions as a sequence of insertions, updates, and deletions. The whole transaction must be undoable as a unit if it fails partway through. Operations need to be logged to disk so they can be replayed after a crash.

Trigger: "We need to group database operations into a transaction and undo the whole thing if any step fails."

Process:

Step 1: Invoker = TransactionManager. Receiver = Database. Client = Application.

Step 2: Full undo interface. Each operation also implements Store() / Load() for crash-recovery logging.

Step 3: InsertCommand captures the inserted row's primary key for Unexecute (DELETE by key). UpdateCommand captures the original row values. DeleteCommand captures the full deleted row.

Step 5: Transaction = MacroCommand. On success, the MacroCommand is placed on history as one unit. On failure midway, MacroCommand.Unexecute() reverses completed sub-commands in reverse order.

Log persistence: after Execute, each sub-command is serialized to a log file. On crash recovery, the log is read and each command's Execute is re-applied.

Output:

Transaction of [InsertCmd, UpdateCmd, DeleteCmd] executes forward; on failure after UpdateCmd, reverse unexecution: [UpdateCmd.Unexecute(), InsertCmd.Unexecute()] — DeleteCmd was never executed so it is not reversed

History after commit: one MacroCommand on the history list, undoable as a unit

Crash recovery: replay log by re-calling Execute on each logged command

---

Example 3: Lexi MenuItem-Command Case Study (from GoF)

Scenario: The Lexi document editor (GoF chapter 2) has dozens of user operations accessible via pull-down menus and keyboard shortcuts. Operations include paste, change font, open document, quit, and save. Some are undoable (paste, font change), some are not (quit, save). MenuItems must not be subclassed per operation — one MenuItem class must serve all cases.

Trigger: "We have too many menu item subclasses — one per operation. Adding a new operation requires a new subclass."

Process:

Step 1: Invoker = MenuItem. Receivers = Document (paste, font), Application (open, quit). Client = Application (configures menus at startup).

Step 2: Command interface has Execute. Undo interface has Unexecute + Reversible.

Step 3:

- PasteCommand(document): Execute calls document.Paste(). Undoable — stores clipboard content. - FontCommand(document, font, range): Execute saves original font, applies new font. Undoable. - OpenCommand(application): Execute prompts user for filename, creates Document, calls application.Add(document), opens it. Not the typical receiver-delegation pattern — the command does all the work itself because there is no pre-existing receiver. - QuitCommand(application): Execute checks if document is modified; if so, calls save.Execute(), then quits. Reversible() = false — not placed on history.

Step 6: Application creates all ConcreteCommand instances at startup, assigns each to the appropriate MenuItem. MenuItem.Clicked() calls history.ExecuteCommand(this._command).

Output:

One MenuItem class handles all operations — the operation is entirely in the Command

Edit menu's Undo item calls history.Undo() — which calls Unexecute() on the last reversible command

QuitCommand does not appear in undo history

Font change on text already in that font: FontCommand.Reversible() checks if font actually changed; returns false if not, preventing a no-op undo entry

---