Master the Command Pattern: Decouple Actions for Flexible Software Design

1. Introduction

The Command pattern is a behavioral design pattern that separates the responsibility of issuing a command from the responsibility of executing it, delegating each to different objects – essentially “everyone does their own job”.

2. Command Pattern

The basic UML class diagram of the Command pattern is shown below:

The pattern defines several roles, which are introduced one by one:

Command : abstract interface for a concrete command.

ConcreteCommand : a concrete implementation of the Command interface; it does not contain business logic itself but delegates the call to a receiver.

Receiver : the ultimate executor of the command; any object can act as a receiver, and it implements the command details.

Invoker : holds a command and triggers its action; it does not create command objects but receives them (usually via constructor) from the client.

Client : creates a concrete command and passes it to the Invoker for execution.

The Command pattern fully decouples the client that initiates a request from the receiver that performs the actual work, improving extensibility. It also enables dynamic parameterization of execution logic through specific Command implementations, allowing composite commands.

3. Plain Explanation

Imagine ordering food at a small eatery without a waiter: you must tell the chef directly, and the chef must deliver the dish to you, which is inefficient. In a larger restaurant, a waiter takes your order, passes it to the chef, and serves the finished dish, providing a smoother experience. This analogy illustrates how the Command pattern separates the requester (client) from the executor (receiver) via an intermediary (invoker).

4. Conclusion

The Command pattern is widely used; for example, the circuit‑breaker component Hystrix and Java’s ThreadPoolExecutor both employ it, making it essential to understand.