Command Pattern: Encapsulating Requests as Objects for Easy Parameterization and Undo Support

In software design, when dealing with a series of operations, developers often face issues such as high code coupling and difficulty in extension. For instance, in a system where users need to perform actions like "open the window," "turn off the air conditioner," or "adjust the lights," traditional approaches typically involve writing multiple independent functions to invoke these features. This structure is not only difficult to maintain but also requires modifying existing logic code whenever a new operation (such as "draw the curtains") needs to be added, which violates the Open/Closed Principle. The Command Pattern was born specifically to address this problem.

The core idea of this pattern is to encapsulate a request as an object, thereby making it easy to parameterize and queue up. Through this mechanism, the receiver can execute specific actions while the invoker simply sends instructions, decoupling their dependency relationship. This allows us to add commands to lists, delay execution, undo operations, or dynamically generate new commands at runtime, significantly enhancing system flexibility and maintainability.
To deeply understand the Command Pattern, it is first necessary to clarify the responsibilities of its four core roles:

  1. Command (Command Interface)
    This serves as the abstraction layer, defining methods that all concrete commands must implement. It typically includes an execute() method for performing operations and optionally a cancel() or undo() method for reversing actions. It acts as the bridge between the client and specific business logic.

  2. ConcreteCommand (Concrete Command)
    A class implementing the Command interface, responsible for encapsulating specific request objects and execution details. Each ConcreteCommand corresponds to a specific functional operation in the system. For example, "open window" is an independent instance of a ConcreteCommand.

  3. Receiver
    The class containing the actual logic code that performs operations. In the Command Pattern, each ConcreteCommand holds a reference to a Receiver and delegates it to complete the task. This ensures that the Command object itself does not contain business details; its sole responsibility is to pass along requests.

  4. Invoker (Invoker)
    The object responsible for initiating and executing concrete commands. It can be a user interface, a scheduled task scheduler, or any module requiring operation triggers. In typical implementations, the Command interface often defines a bind(Receiver) method so that the Invoker can dynamically bind specific receivers to commands together.

Classic Scenario: Smart Home Control System

To more intuitively demonstrate the application value of the Command Pattern, we can construct a simplified "Smart Home System" as an example scenario. In this scenario, users control home appliances (the Receiver) via their mobile app (the Invoker), without needing to directly manipulate the underlying code of the devices.

Assume we have a basic Light class serving as the receiver:

class Light:
    def turn_on(self):
        print("Lights are turned on")
    
    def turn_off(self):
        print("Lights are turned off")

Next, let's define the command interface and concrete commands. When a user wants to "turn on the light," the system creates a TurnOnLight object; if the user regrets it and wishes to undo that action, an UndoTurnOnLight object is created:

  • Forward Execution: Invoker sends "Open" instruction -> Command encapsulates request -> Receiver executes action.
  • Reverse Undoing: System maintains a history command stack -> Pops the most recent Command -> Calls its corresponding cancellation logic or regenerates an opposite command.

This design allows us to unify all possible operations (such as turning on/off lights, adjusting brightness) into a single "task queue." Whether adding new appliance control features anytime and anywhere only requires creating the corresponding ConcreteCommand class without modifying the existing Invoker structure. This perfectly embodies the principle of high cohesion and low coupling.

Implementation Steps and Code Practice

When applying the Command Pattern in actual development, developers typically follow three key steps: first defining a generic Command interface; second, creating specific command classes and binding receiver objects; third, triggering the execution flow via an invoker. It is worth noting that in scenarios involving undo functionality, we often need to maintain a "Command Stack" (or History) to save executed instructions for subsequent rollback operations.

Below is a simplified implementation logic based on Python:

  1. Define Interface: Create a Command base class declaring the execute(), undo(), and bind(receiver) methods.
  2. Concrete Commands: Write corresponding ConcreteCommand subclasses for each business operation (e.g., "turn off air conditioner"). Bind specific Receiver instances within their constructors.
  3. Build Invocation Chain: Create a Manager class acting as the Invoker, maintaining both a command list and an undo stack. When users submit new requests, push them onto the execution queue; if cancellation is needed, pop from the undo stack and execute the reverse operation.

Through this approach, complex business logic is isolated within specific command objects while control flow becomes clear and transparent. Whether handling asynchronous processing, logging, or transaction rollback can be easily added as functional modules at the Invoker layer without affecting the stability of underlying receivers. This architecture not only reduces coupling between components but also significantly enhances extensibility, making it an ideal choice for constructing complex business logic systems.