<\/div> <\/div><\/p>\n
\n# file: command.py\nfrom abc import ABC, abstractmethod\n\nclass Command(ABC):\n @abstractmethod\n def execute(self):\n pass\n<\/pre>\n2.1.1 Code Explanation<\/h4>\n
The above code defines an abstract base class named Command<\/code> using Python\u2019s abc<\/code> (Abstract Base Classes) module, which is designed to enforce a common interface across all concrete command implementations in the Command Pattern. By inheriting from ABC<\/code>, the Command<\/code> class becomes an abstract class, meaning it cannot be instantiated directly and is intended to be subclassed. The @abstractmethod<\/code> decorator is applied to the execute()<\/code> method, ensuring that any subclass of Command<\/code> must provide its own implementation of this method. The execute()<\/code> method represents the core operation that encapsulates a request, and although it contains only a pass<\/code> statement here (indicating no default behavior), it acts as a contract that enforces consistency across all command objects. This structure is crucial in the Command Pattern because it allows the invoker to call execute()<\/code> on any command object without needing to know the details of how the request is processed, thereby achieving loose coupling between the sender and the receiver.<\/p>\n2.2 Implementing the Receiver<\/h3>\n
The following code defines the receiver class that contains the actual business logic.<\/p>\n
\n# file: light.py\nclass Light:\n def turn_on(self):\n print(\"Light is ON\")\n\n def turn_off(self):\n print(\"Light is OFF\")\n<\/pre>\n2.2.1 Code Explanation<\/h4>\n
The above code defines a Receiver class named Light<\/code>, which represents the object that performs the actual work in the Command Pattern. It contains two methods: turn_on()<\/code> and turn_off()<\/code>, each encapsulating a specific piece of business logic\u2014in this case, printing the state of the light. These methods simulate real-world actions (such as controlling a physical light device), but in practice, they could include more complex operations like interacting with hardware or external systems. The Light<\/code> class itself is unaware of the Command Pattern or how its methods are invoked; it simply exposes functionality. This separation of concerns is important because command objects (like LightOnCommand<\/code> and LightOffCommand<\/code>) will call these methods without the invoker needing to know any details about the Light<\/code> class, thereby maintaining loose coupling and making the system more modular and extensible.<\/p>\n2.3 Creating Concrete Commands<\/h3>\n
The following code implements concrete command classes that bind actions to the receiver.<\/p>\n
\n# file: light_commands.py\nfrom command import Command\n\nclass LightOnCommand(Command):\n def __init__(self, light):\n self.light = light\n\n def execute(self):\n self.light.turn_on()\n\n\nclass LightOffCommand(Command):\n def __init__(self, light):\n self.light = light\n\n def execute(self):\n self.light.turn_off()\n<\/pre>\n2.3.1 Code Explanation<\/h4>\n
The above code defines two Concrete Command classes\u2014LightOnCommand<\/code> and LightOffCommand<\/code>\u2014which implement the abstract Command<\/code> interface and provide specific actions to be executed. Each class takes an instance of the Light<\/code> receiver as a dependency through its constructor (__init__<\/code>) and stores it as an instance variable. This establishes a connection between the command and the receiver it will act upon. The execute()<\/code> method in each class overrides the abstract method defined in the base Command<\/code> class and delegates the actual work to the receiver by calling the appropriate method\u2014turn_on()<\/code> for LightOnCommand<\/code> and turn_off()<\/code> for LightOffCommand<\/code>. This encapsulation of a request as an object allows the invoker to trigger these commands without knowing any details about the Light<\/code> class or the specific operations being performed, thereby achieving loose coupling and enabling flexibility such as easily adding new commands or changing behavior at runtime.<\/p>\n2.4 Implementing the Invoker<\/h3>\n
The following code defines the invoker that triggers command execution.<\/p>\n
\n# file: remote_control.py\nclass RemoteControl:\n def __init__(self):\n self.command = None\n\n def set_command(self, command):\n self.command = command\n\n def press_button(self):\n if self.command:\n self.command.execute()\n<\/pre>\n2.4.1 Code Explanation<\/h4>\n
The above code defines the Invoker class named RemoteControl<\/code>, which is responsible for triggering command execution without knowing the details of how the command is implemented. The class maintains a reference to a command object through the instance variable self.command<\/code>, which is initially set to None<\/code>. The set_command()<\/code> method allows the client to assign any concrete command (such as LightOnCommand<\/code> or LightOffCommand<\/code>) to the invoker dynamically, enabling flexible behavior at runtime. The press_button()<\/code> method acts as the trigger mechanism; it checks whether a command has been set and, if so, calls its execute()<\/code> method. Importantly, the RemoteControl<\/code> class does not know anything about the receiver (e.g., Light<\/code>) or the specific action being performed\u2014it simply invokes the command interface. This abstraction is a key benefit of the Command Pattern, as it decouples the invoker from the actual business logic, making the system more modular, extensible, and easy to maintain.<\/p>\n2.5 Client Code<\/h3>\n
The following code shows how all components are wired together and executed.<\/p>\n
\n# file: main.py\nfrom light import Light\nfrom light_commands import LightOnCommand, LightOffCommand\nfrom remote_control import RemoteControl\n\nif __name__ == \"__main__\":\n # Receiver\n light = Light()\n\n # Commands\n light_on = LightOnCommand(light)\n light_off = LightOffCommand(light)\n\n # Invoker\n remote = RemoteControl()\n\n # Turn ON\n remote.set_command(light_on)\n remote.press_button()\n\n # Turn OFF\n remote.set_command(light_off)\n remote.press_button()\n<\/pre>\n2.5.1 Code Explanation<\/h4>\n
The above code represents the Client section, where all components of the Command Pattern are instantiated and wired together to demonstrate how the pattern works in practice. The execution starts with the creation of the Light<\/code> object, which acts as the receiver containing the actual business logic. Next, two concrete command objects\u2014LightOnCommand<\/code> and LightOffCommand<\/code>\u2014are created, each receiving the light<\/code> instance so they can delegate actions to it. Then, an instance of the RemoteControl<\/code> (the invoker) is created, which will be used to trigger commands. The client dynamically assigns commands to the invoker using the set_command()<\/code> method, first setting the light_on<\/code> command and calling press_button()<\/code> to execute it, resulting in turning the light on. The process is then repeated with the light_off<\/code> command to turn the light off. This flow clearly demonstrates how the client configures the system and how the invoker remains completely unaware of the underlying implementation details, relying solely on the command interface to execute actions, thereby achieving loose coupling and runtime flexibility.<\/p>\n2.6 Running the Application and Output<\/h3>\n
The following output shows the result of executing the command pattern implementation.<\/p>\n
\nLight is ON\n\nLight is OFF\n<\/pre>\nThe above output demonstrates the result of executing the Command Pattern implementation, where the invoker (RemoteControl<\/code>) triggers different commands assigned to it at runtime. When the light_on<\/code> command is set and the button is pressed, the execute()<\/code> method of LightOnCommand<\/code> is invoked, which internally calls the turn_on()<\/code> method of the Light<\/code> receiver, resulting in the output \"Light is ON\"<\/code>. Similarly, when the light_off<\/code> command is assigned and executed, it triggers the turn_off()<\/code> method of the receiver, producing \"Light is OFF\"<\/code>. This output validates how the Command Pattern enables dynamic behavior by allowing different commands to be executed through the same invoker interface, without the invoker needing to know any details about the underlying actions or receiver logic.<\/p>\n