Python命令模式，如何解耦请求与执行者？

Python中的命令模式是一种行为设计模式,它将请求封装为对象，从而允许用户使用不同的请求、队列或日志请求来参数化其他对象，并支持可撤销的操作，这种模式的核心思想是将“发出请求的对象”与“接收并执行请求的对象”解耦，使得请求本身可以像对象一样被传递、存储和管理。

在命令模式中,通常包含以下几个关键角色：接收者（Receiver）、命令（Command）、调用者（Invoker）和客户端（Client），接收者是真正执行请求的对象，包含具体的业务逻辑；命令是一个抽象接口，定义了执行请求的方法，通常包含对接收者的引用；调用者是调用命令的对象，它不知道具体如何执行请求，只知道如何调用命令对象；客户端则负责创建具体的命令对象并将其与接收者关联起来。

在Python中实现命令模式时,可以利用其动态类型和灵活的类特性，可以通过定义一个抽象基类或接口来规范命令的行为，然后创建具体的命令类继承该基类，每个具体命令类会持有一个接收者对象的引用，并在其执行方法中调用接收者的相应方法，调用者则通过调用命令对象的执行方法来触发请求，而不需要知道接收者的具体实现。

以下是一个简单的Python代码示例,展示了命令模式的基本实现：

from abc import ABC, abstractmethod
# 接收者
class Receiver:
    def action(self):
        print("Receiver is performing action.")
# 抽象命令
class Command(ABC):
    @abstractmethod
    def execute(self):
        pass
# 具体命令
class ConcreteCommand(Command):
    def __init__(self, receiver):
        self._receiver = receiver
    def execute(self):
        self._receiver.action()
# 调用者
class Invoker:
    def __init__(self):
        self._command = None
    def set_command(self, command):
        self._command = command
    def execute_command(self):
        if self._command:
            self._command.execute()
# 客户端代码
if __name__ == "__main__":
    receiver = Receiver()
    command = ConcreteCommand(receiver)
    invoker = Invoker()
    invoker.set_command(command)
    invoker.execute_command()  # 输出: Receiver is performing action.

在这个例子中,Receiver类是真正的执行者，ConcreteCommand类封装了对Receiver的调用，Invoker类负责触发命令的执行，而客户端则将各个部分组装起来，通过这种方式，调用者（Invoker）与接收者（Receiver）完全解耦，调用者只需要知道如何调用命令对象，而不需要了解接收者的具体实现。

命令模式在实际应用中有多种变体和扩展,可以实现宏命令，即一个命令对象可以管理多个子命令，当执行宏命令时，会依次执行所有子命令，还可以支持撤销操作，通过为命令对象添加一个undo方法，并在执行命令后记录其状态，以便在需要时恢复，这种扩展在图形界面、文本编辑器等需要撤销/重做功能的场景中非常常见。

以下是一个支持撤销操作的命令模式示例：

# 接收者
class Light:
    def turn_on(self):
        print("Light is on.")
    def turn_off(self):
        print("Light is off.")
# 命令类
class LightCommand(Command):
    def __init__(self, light):
        self._light = light
        self._previous_state = None
    def execute(self):
        self._previous_state = getattr(self._light, 'is_on', False)
        self._light.turn_on()
    def undo(self):
        if self._previous_state:
            self._light.turn_off()
        else:
            self._light.turn_on()
# 调用者
class RemoteControl:
    def __init__(self):
        self._commands = []
        self._undo_commands = []
    def set_command(self, command):
        self._commands.append(command)
    def execute_command(self):
        if self._commands:
            command = self._commands.pop()
            command.execute()
            self._undo_commands.append(command)
    def undo_command(self):
        if self._undo_commands:
            command = self._undo_commands.pop()
            command.undo()
# 客户端代码
if __name__ == "__main__":
    light = Light()
    light_on = LightCommand(light)
    remote = RemoteControl()
    remote.set_command(light_on)
    remote.execute_command()  # 输出: Light is on.
    remote.undo_command()     # 输出: Light is off.

在这个扩展示例中,LightCommand类记录了执行前的状态，并通过undo方法恢复状态。RemoteControl类维护了命令队列和撤销队列，支持执行和撤销操作。

命令模式的优势在于它将请求的发送者和接收者解耦,使得系统更灵活、可扩展，通过引入命令对象，可以方便地添加新功能，例如日志记录、事务处理或延迟执行，命令模式还支持宏命令和撤销操作，适用于需要复杂请求管理的场景。

命令模式也有一些缺点,由于引入了额外的命令类，可能会导致系统中的类数量增加，从而增加系统的复杂性，如果请求的参数或接收者的方法频繁变化，可能需要频繁修改命令类的实现，这可能会影响系统的维护性。

以下是命令模式在不同场景下的应用示例表格：

Python中的命令模式通过将请求封装为对象,实现了发送者和接收者的解耦，提高了系统的灵活性和可扩展性，它适用于需要支持撤销、宏命令、事务管理等复杂功能的场景，但也可能增加系统的类数量和复杂性，在实际开发中，应根据具体需求权衡是否使用命令模式，以及如何合理设计命令类和调用者之间的关系。

相关问答FAQs：

1. 问：命令模式与观察者模式有什么区别？
   答：命令模式的核心是将请求封装为对象，使请求的发送者和接收者解耦，主要用于支持撤销、宏命令等功能；而观察者模式定义了对象间的一对多依赖关系，当一个对象状态变化时，所有依赖它的对象都会收到通知，主要用于实现事件驱动和响应式编程，两者的关注点不同，命令模式侧重于请求的封装和管理，观察者模式侧重于对象间的通信和通知。

2. 问：在Python中，如何使用函数式编程风格实现命令模式？
   答：Python支持将函数作为一等对象，因此可以通过闭包或lambda函数实现命令模式，可以将接收者的方法作为函数传递给命令对象，而不需要显式定义命令类，示例代码如下：

   def make_command(receiver_method):
       def command():
           receiver_method()
       return command
   class Receiver:
       def action(self):
           print("Receiver is performing action.")
   receiver = Receiver()
   command = make_command(receiver.action)
   command()  # 输出: Receiver is performing action.

   这种方式减少了类的定义,适用于简单的命令封装场景，但可能不如基于类的实现灵活和可扩展。