为什么命令模式在面向对象设计中很方便?

ane*_*yzm 15 oop design-patterns command-pattern

我不明白为什么Command模式在面向对象的设计中很方便.

而不是使用,例如Switch具有Lamp类的引用的Command ,我不能只创建一个Switchable抽象类并调用它的方法?

通过这种方式,我无论如何都要将调用者和接收者分离,而且我不必为每个接收者类创建一个Command对象.

Rob*_*evy 13

Switchable在调用者和接收者之间创建了一个抽象,但它们仍然是耦合的(调用者需要对接收者的引用).命令模式允许您创建该解耦.调用者对一些中间组件说" 嘿,我有这个命令,我想要执行 ",然后中间件可以动态地将该请求传递给接收器.

ps ...我猜你从维基百科中提取了Switch的例子.这是为什么这种模式有用的一个非常糟糕的例子.看看更好的例子.

  • @Patrick,通过保持它们分开,您可以交换我们的接收器而无需更改调用者(反之亦然).因此,更易于维护.还有一些情况是,在运行时基于配置文件,用户输入或某些数据源,无法确定调用者和接收者之间的连接. (2认同)

kev*_*ine 9

假设您要制作如下列表:

  • 打开灯泡
  • 设置A/C温度
  • 玩"月亮河"

动作和接收器都是不同的,因此您需要一个与所有动作分离的抽象.当您想要支持撤消/重做或类似的事情时,Command模式也会派上用场.


AKS*_*AKS 7

让我们看一下:当客户希望接收器执行某些任务时,客户端有两个选项,

  1. 呼叫接收者并告诉他执行任务.
  2. 打电话给知道接收者的第三方,第三方将消息传递给接收者.

第一个选项看起来更好,就像想到场景一样,当没有服务员在餐厅接受订单时你必须去厨师告诉他你想要什么.

或者假设您丢失了遥控器,您必须转到电视并手动切换按钮.

它提供了灵活性,因此命令不仅可以在同步模式下执行,还可以在异步模式下执行.


bha*_*ran 5

You -> Switch -> Light
Run Code Online (Sandbox Code Playgroud)

在这里,开关将你与灯光分离.因此,使用开关可以更轻松地打开/关闭灯光.这是使用(方便)使用命令模式.

你 - 命令调用
开关 - 命令管理器
命令 - 打开/关闭
灯 - ​​实际执行者

如果没有命令模式,则必须在需要时手动将灯放入支架中,并在不需要时将其移除.