我正在学习命令设计模式。据我所知,与命令模式相关的四个术语是命令、接收者、调用者和客户端。
具体的命令类有一个execute()
方法,调用者有几个命令。调用者决定何时调用execute()
命令的方法。
当execute()
方法被调用时,它会调用接收者的方法。然后,接收器完成工作。
我不明白为什么我们需要接收器类?我们可以在execute()
方法里面做,看来receiver类是多余的。
预先感谢。
我正在学习命令设计模式。据我所知,与命令模式相关的四个术语是命令、接收者、调用者和客户端。
具体的命令类有一个execute()
方法,调用者有几个命令。调用者决定何时调用execute()
命令的方法。
当execute()
方法被调用时,它会调用接收者的方法。然后,接收器完成工作。
我不明白为什么我们需要接收器类?我们可以在execute()
方法里面做,看来receiver类是多余的。
预先感谢。
设计模式用于解决软件问题。
在尝试理解解决方案之前,您必须先理解问题(在本例中为命令模式)
命令模式应用的问题是在对象 A(客户端)调用对象 B(接收器)中的方法的上下文中,因此接收器是问题的一部分,而不是解决方案的一部分。
命令模式提供的解决方案或想法是将A到B的方法调用封装在一个对象(Command)中,实际上这接近于正式的模式定义。当您将请求作为对象进行管理时,您可以解决一些问题或实现一些功能。(您还需要其他部件,例如 Invoker)
这个列表可以给你一些很好的例子,说明什么样的问题或特性适合命令模式。
注意:comamnd 模式不需要解耦,实际上最常见的示例模式实现,客户端需要创建一个新的接收器实例,所以我们不能在这里讨论解耦。
想象一个可以做几件事的类,比如 Duck,它可以吃东西和嘎嘎叫。在这个例子中,Duck 是一个接收器。要在此处应用命令模式,您需要能够将吃和呱呱打包成一个命令。它们应该是从带有execute()
方法的 Command 基类派生的单独类,因为 Duck 只能有一个execute()
方法。所以EatCommand.execute()
呼唤Duck.eat()
和QuackCommand.execute()
呼唤Duck.quack()
。
命令模式的目标是将调用者与接收者分离。
接收者必须完成工作,而不是命令本身,命令只知道要调用的接收者方法是什么,或者命令可以执行其他命令。使用命令模式,调用者不知道该命令的期望是什么。
因此,许多调用者可以重用一个命令来在接收者上执行相同的操作。
简短的回答取决于。这不仅仅基于我的观点。来自 GOF,命令模式,实现(第 238 页)
“一个命令应该有多智能?一个命令可以具有广泛的能力。在一个极端,它只是定义了接收者和执行请求的动作之间的绑定。在另一个极端,它自己实现一切,而不委托给完全接收器。当您想要定义独立于现有类的命令时,当不存在合适的接收器时,或者当命令隐式知道其接收器时,后一种极端很有用。例如,创建另一个应用程序窗口的命令可能只是像任何其他对象一样能够创建窗口。”
所以我认为不应该仅仅为了它而创建一个接收器类,或者因为大多数例子都是这样说的。只有在真正需要时才创建它。一种这样的情况是,充当接收者的类已经作为单独的类存在。如果您必须编写将要被调用/执行的代码并且没有理由为此创建一个单独的类,那么我认为将调用程序代码添加到 Command 本身没有任何错误。