Think of the Command Pattern as a remote control for your code. Instead of telling an object exactly what to do, you wrap the request in a command object. This object can then be executed immediately, scheduled for later, or even undone.
In simple terms, the Command Pattern turns requests into objects. This gives your code more flexibility to:
-
Queue requests
-
Log actions
-
Undo or redo operations
-
Change behavior without modifying the objects that perform the actions
This makes the system easier to extend and maintain, and it decouples the part of the code that sends a request from the part that performs it.
Example: Smart Home Automation
Imagine a smart home system. You want to:
-
Turn the lights on
-
Switch the fan off
-
Undo the last action
Instead of writing separate methods for each device, you create command objects like:
-
LightOnCommand -
FanOffCommand -
UndoLastCommand
Each command knows exactly which device it controls and how to perform the action. The main controller, called the Invoker, doesn’t need to know the details of the device. It simply executes the command when requested.
Think of it like a universal smart remote. The remote doesn’t care what the device is, as long as the right command object is passed to it.
UML Diagram
Key Components of the Command Pattern
-
Command Interface – Defines a common method, usually
execute(), that all commands implement. -
Concrete Command – Implements the Command interface and links a specific action to a Receiver. It knows exactly what to do and which parameters to use.
-
Receiver – The object that actually performs the work, like a TV, light, or fan.
-
Invoker – Holds a command and triggers its execution. It doesn’t know how the action works, only that it can call
execute(). -
Client – Creates a Concrete Command, sets its Receiver, and passes it to the Invoker.
Why Use the Command Pattern?
The Command Pattern is useful when you need flexibility and want to separate responsibilities:
-
Decoupling – The part of the code that triggers an action (controller) doesn’t need to know how the action works.
-
Extensibility – You can add new commands without changing the existing code.
-
Undo/Redo – Easily reverse actions by keeping a history of commands.
-
Automation – Fits well in smart systems, task schedulers, or IoT platforms where actions may need to be queued or repeated.
When to Use It
-
When you want to separate the sender from the receiver for flexibility.
-
When you need undo or redo functionality.
-
When you want to queue or log actions.
-
When you need dynamic configuration, combining commands at runtime.
When Not to Use It
-
For simple one-time tasks, it may be overkill.
-
If tight coupling is acceptable, you don’t need this pattern.
-
For performance-critical code, the extra abstraction may add unnecessary overhead.
If undo/redo isn’t required, the pattern may complicate things unnecessarily.
UML Diagram
Summary
The Command Pattern is like a smart remote control for your code, it wraps actions in command objects that can be executed, queued, or undone without the caller needing to know the details. Each command knows which device or object to control, while an invoker triggers the action. This pattern makes code flexible, decouples the sender from the receiver, supports undo/redo, and allows easy addition of new commands. It’s useful in systems like smart homes, task schedulers, or automation tools, but may be overkill for simple, one-time tasks.