uml命令模式图

Question

我需要帮助来理解命令模式。 在UML图中，客户端应该有一个与Invoker的关联箭头，为什么没有显示？ 谁在打电话给Invoker？ 如果它是客户端，它是否应该关联Invoker？

Answer 1

Preliminary remarks

The illustration and explanations that you have inserted in your question are directly extracted from "Design Patterns, elements of reusable OO software"，即GoF。

作为初步评论，这本书写于1995年并使用詹姆斯Rumbaugh's OMT（该书的详细信息见本书第14页及其附件B）。在此图表中，类图用箭头显示原始对象保持对箭头侧对象的引用的关联。

（顺便说一下，UML，即使已经在1995年底发布了一个preversion，也只是在1997年的1.0版中正式化了）

Client和Invoker

之间没有直接的结构关系

我认为Thomas Kilian之前已经回答了这个问题。

类图（标题＆＃34;结构＆＃34;）清楚地表明Client不必与Invoker相关。

但是还有更多的论点：在关于参与者和合作的解释中，没有任何关于Client和Invoker之间关系的说法。示例C ++代码也没有，它会详细介绍Invoker，Command和Receiver。

Client和Invoker之间建议的唯一关系可在交互图中找到， 说明 如何Command将Invoker与Receiver ＆＃34;分开。顺便说一句，在本书的第347页，讨论了行为模式如何解耦对象。再次呈现Command模式的交互图，这次没有任何客户端。

基于所有这些元素，我指出图中Client和Invoker之间的交互仅仅是说明性的，并且是为了避免引入更多对象。

还有疑问吗？

然后我建议去标题＆＃34; Motivation＆＃34;在抽象模式之前用实际例子解释了模式的意图。

类图p.233是我之前声明的证明。在此图中，您有Client（称为Application）。客户端与Receiver（称为Document）之间存在关联。 Command和Invoker之间存在关系（称为MenuItem）。 Client/Application和Invoker/MenuItem之间没有任何关系。但是Application与Menu有关系，Menu是几个MenuItem的聚合。所以在这个例子中存在间接关系。

因此，在模式中，Client和Invoker之间的直接关系不是必需的。当然有很多例子表明这种关系是有意义的（它也没有说它是禁止的！）。还有一些关系是间接的例子。但这种模式不需要它。您当然可以想到有效的架构，其中没有关系，甚至客户端和Invoker之间也没有间接关系。