Command Pattern

Definition

The Command pattern is a behavioral design pattern that encapsulates a request or action as a standalone object, allowing it to be parameterized, queued, logged, undone, or executed at a different time than when it was created.

Overview

The Command pattern, catalogued by the Gang of Four, turns a request into a first-class object rather than a direct method call. A command object typically implements a simple interface (commonly a single `execute()` method), and internally holds a reference to the receiver (the object that actually performs the work) along with any parameters needed to perform the action. The invoker — whatever code triggers the action, such as a UI button or a menu item — holds a reference to a command object and calls `execute()` on it without needing to know any details about what the command actually does or which receiver it targets. This indirection unlocks several capabilities that direct method calls don't easily provide. Because a command is a full object, it can be stored in a list and executed later (queuing, task scheduling, deferred execution), logged for auditing or replay, or serialized and sent across a network (as in remote procedure calls or distributed job queues). Many implementations also add an `undo()` method to the command interface, letting the invoker maintain a history of executed commands and reverse them in order — this is the standard mechanism behind undo/redo functionality in text editors, graphics applications, and IDEs. A related technique, the macro command, composes multiple commands into a single composite command that executes them in sequence, treating a group of actions as one undoable unit. Command is closely related to task queues and job scheduling systems in backend engineering: a 'job' submitted to a message queue (like a background job processor) is essentially a serialized command object, decoupling the code that decides work needs to happen from the code (a worker process) that eventually performs it. It also underlies the general architecture of CQRS (Command Query Responsibility Segregation), where 'commands' are explicit objects representing an intent to change state, distinct from queries that read state, and each command can be validated, logged, and routed to an appropriate handler independently.

Key Concepts

• Encapsulates a request/action as a standalone object with an execute() method
• Decouples the invoker (who triggers the action) from the receiver (who performs it)
• Enables queuing, logging, scheduling, or deferring execution of actions
• Commonly extended with an undo() method to support undo/redo functionality
• Supports composite 'macro' commands that group multiple commands into one undoable unit
• Maps naturally onto background job/task queue architectures
• Foundational to CQRS, where commands are explicit, validated, first-class intent objects
• Can be serialized for network transmission (remote execution, distributed job systems)

Use Cases

Frequently Asked Questions

Related in Programming