为什么我们在Command设计模式中需要一个“接收器”类

时间:2013-05-15 09:31:44

标签: oop design-patterns

我正在学习命令设计模式。据我所知,总是与命令模式相关的四个术语是命令,接收者,调用者和客户端。

具体的命令类有execute()方法,调用者有几个命令。调用者决定何时调用命令的execute()方法。

调用execute()方法时,它会调用接收方的方法。然后,接收者完成工作。

我不明白为什么我们需要接收器类?我们可以在execute()方法中完成工作,似乎接收器类是多余的。

提前感谢。

4 个答案:

答案 0 :(得分:7)

想象一个可以做几件事的课程,比如Duck,它可以吃和嘎嘎。在这个例子中,Duck是接收器。要在此处应用命令模式,您需要能够将吃和嘎嘎声包装到命令中。它们应该是使用execute()方法从Command基类派生的单独类,因为Duck只能使用单execute()方法。因此EatCommand.execute()调用了Duck.eat()QuackCommand.execute()来调用Duck.quack()

答案 1 :(得分:7)

设计模式用于解决软件问题。

在尝试理解解决方案(在本例中为Command模式)之前,您必须先了解问题

命令模式适用的问题是在对象A(客户端)调用对象B(接收器)中的方法的上下文中,因此Receiver是问题的一部分,而不是解决方案的一部分。

命令模式提供的解决方案或想法是在对象(Command)中将方法调用从A封装到B,实际上这接近于正式模式定义。将请求作为对象进行管理时,您可以解决某些问题或实现某些功能。 (你还需要其他一些名为Invoker的作品)

这个list可以为您提供一些很好的示例,说明哪些特征适合命令模式。

注意:Comamnd模式不是关于解耦的必要条件,实际上是最常见的模式实现示例,客户端需要创建接收器的新实例,所以我们不能在这里谈论解耦。

答案 2 :(得分:6)

命令模式的目标是将调用者与接收者分离。

接收方必须完成工作,而不是命令本身,命令只知道接收方法的调用方式,或者命令可以执行其他命令。使用命令模式,调用者不知道命令所期望的是什么。

因此,许多调用者可以重复使用命令在接收器上执行相同的操作。

答案 3 :(得分:1)

简短答案取决于。这并非仅基于我的观点。在GOF中,命令模式,实现(第238页)

“命令应该有多聪明?命令可以具有多种功能。在一个极端情况下,它仅定义了接收方和执行请求的动作之间的绑定。在另一个极端情况下,它自己实现了所有内容而没有执行完全委派给接收方。当您要定义独立于现有类的命令,不存在合适的接收方或命令隐式知道其接收方时,后一种极端非常有用,例如,创建另一个应用程序窗口的命令可能与创建其他任何对象一样具有创建窗口的能力。”

因此,我不认为一个人应该仅仅为了它而创建一个接收器类,或者因为大多数示例都这样说。仅在确实有需要时才创建它。一个这样的情况是,充当接收者的类已经作为单独的类存在。如果您必须编写将要被调用/执行的代码,并且没有理由为此创建一个单独的类,那么在将调用者代码添加到Command本身时,我看不到任何错误。