Design patterns GOF模式UML图中的依赖关系箭头

我或多或少都清楚什么是GOF模式以及它们的行为
然而，我觉得我错过了一些全局性的东西（在UML或模式中），因为如果我试图在脑海中重复它们，我会在许多GOF类图中画一个或两个额外的箭头。我理解UML图不必显示所有的连接，但为什么不是所有的连接都在简洁的模式图中

举几个例子：

工厂方法UML图：

为什么从创建者到产品之间没有关联线（普通实心箭头）？FactoryMethod有一个注释：“product=FactoryMethod（）”。这意味着创建者会跟踪产品。为什么UML中没有连接

命令模式UML图：

为什么调用程序是孤立的？客户机与接收方关联，取决于具体的命令，但它需要将命令传递给调用方。为什么客户端和调用程序之间没有连接

---

谢谢你的回答。

你把结构和行为搞混了

关联意味着结构依赖，通常是“has”关系。A有一个B。然而，这更像是“比尔有一个手指”，而不是“比尔有一个钱包”。比尔有时可能有一个钱包，但从结构上讲，这并不是比尔作为人的定义

Creator有产品吗？不，不是结构上的。也不创造造物主。他们实例化一个产品，然后返回它（我不确定实现关联是否合适，从来没有想过返回实现它的东西）。在大多数情况下，他们不跟踪产品

考虑一个类Chef，它创建了一个用餐对象。厨师在将饭菜退回给顾客课堂后，是否会对其进行跟踪？不，他在吃下一顿饭。因此，厨师和膳食之间没有联系

是的，的确厨师在做一顿饭的时候会暂时拥有一顿饭，但这顿饭不是厨师的一个结构部分。他只负责制作膳食并将其交给消费者。对象图显示对象的结构，而不是对象的方法所做的。这是另一种图，比如活动图

至于命令模式问题，调用程序取决于接口，而不是命令对象本身。因为调用程序只依赖于接口，所以您可以将实现接口的任何类型的对象传递给它。它甚至不必是命令，只要它假装是命令

---

调用者不知道它在调用什么，所以没有依赖关系和关联。举个例子，考虑到有人蒙蔽了你，并要求你识别他们给你的对象。您可能能够分辨出多少对象，但有些对象可能无法分辨。例如，你可能不知道面包面团和玩具面团之间的区别，或者一个大橘子和一个小葡萄柚之间的区别。无论出于何种目的，一个大橘子和一个小葡萄柚实现了相同的触觉界面，但当你执行它们（吃掉它们）时，它们会产生不同的结果。

你把结构和行为混淆了

关联意味着结构依赖，通常是“has”关系。A有一个B。然而，这更像是“比尔有一个手指”，而不是“比尔有一个钱包”。比尔有时可能有一个钱包，但从结构上讲，这并不是比尔作为人的定义

Creator有产品吗？不，不是结构上的。也不创造造物主。他们实例化一个产品，然后返回它（我不确定实现关联是否合适，从来没有想过返回实现它的东西）。在大多数情况下，他们不跟踪产品

考虑一个类Chef，它创建了一个用餐对象。厨师在将饭菜退回给顾客课堂后，是否会对其进行跟踪？不，他在吃下一顿饭。因此，厨师和膳食之间没有联系

是的，的确厨师在做一顿饭的时候会暂时拥有一顿饭，但这顿饭不是厨师的一个结构部分。他只负责制作膳食并将其交给消费者。对象图显示对象的结构，而不是对象的方法所做的。这是另一种图，比如活动图

至于命令模式问题，调用程序取决于接口，而不是命令对象本身。因为调用程序只依赖于接口，所以您可以将实现接口的任何类型的对象传递给它。它甚至不必是命令，只要它假装是命令

---

调用者不知道它在调用什么，所以没有依赖关系和关联。举个例子，考虑到有人蒙蔽了你，并要求你识别他们给你的对象。您可能能够分辨出多少对象，但有些对象可能无法分辨。例如，你可能不知道面包面团和玩具面团之间的区别，或者一个大橘子和一个小葡萄柚之间的区别。出于各种目的，一个大橘子和一个小葡萄柚实现了相同的触觉界面，但当你执行它们（吃掉它们）时，它们会产生不同的结果。

谢谢你的时间，Mystere Man。创作者没有一个产品结构是一个很好的观点。然而，在命令模式中，我想知道客户机调用程序连接。调用器命令连接对我来说似乎很清楚。对我来说，客户端和调用程序之间的依赖关系是非常结构化的。客户端创建或接收已创建的调用程序并向其发送命令。这里的逻辑是什么？@Alex-客户机和调用程序之间可能存在关联，但该模式不需要关联。例如，当使用依赖项注入系统时，调用程序不会调用创建者来创建对象。他仅仅依赖于传递给它的接口。您的实现可能会创建一个依赖项，但模式本身并不需要它。创作者没有一个产品结构是一个很好的观点。然而，在命令模式中，我想知道客户机调用程序c