GOF 模式 UML 图中的依赖关系箭头
我或多或少清楚 GOF 模式是什么以及它们的行为方式。
然而，我觉得我错过了一些全局性的东西（在 UML 或模式中），因为如果我试图在脑海中重复它们，我会在许多 GOF 类图中画出一个或两个额外的箭头。我知道 UML 图不必显示所有连接，但为什么不是所有连接都以简洁的模式图表示。
几个例子：
工厂方法 UML 图：
http://en.wikipedia.org/wiki/Factory_method_pattern
为什么没有关联线（纯实线箭头）从创造者到产品？ FactoryMethod 有一个注释：“product = FactoryMethod()”。这意味着创建者会跟踪产品。为什么UML中没有连接？
命令模式UML图：
http://en.wikipedia.org/wiki/Command_pattern
为什么 Invoker 是孤立的？ Client与Receiver关联，依赖于Concrete命令，但需要将命令传递给Invoker。为什么客户端和调用者之间没有连接？
感谢您的回答。
It's more or less clear to me what GOF patterns are and how they behave.
However, I feel I miss something global (in UML or patterns), as I'd draw an extra arrow or two in many GOF class diagrams if I try to repeat them from my mind. I understand that UML diagram doesn't have to show all connections, but why not all connections are in concise pattern diagrams.
A couple of examples:
Factory Method UML diagram:
http://en.wikipedia.org/wiki/Factory_method_pattern
Why no association line (plain solid arrow) from Creator to Product? There is a note for FactoryMethod: "product = FactoryMethod()". It means Creator keeps track of Product. Why there is no connection in UML?
Command pattern UML diagram:
http://en.wikipedia.org/wiki/Command_pattern
Why Invoker is orphaned? Client is associated with Receiver, depends on Concrete command, but it needs to pass the command to Invoker. Why no connection between Client and Invoker?
Thanks for your answers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您将结构与行为混淆了。
关联意味着结构依赖性，通常是“具有”关系。 A 有一个 B。然而，这更像是“Bill 有一个手指”而不是“Bill 有一个钱包”。比尔有时可能有一个钱包，但这并不是从结构上将比尔定义为人类的东西。
Creator有产品吗？不，结构上不是。 Concreate Creator 也没有。他们实例化一个 Product，然后返回它（我不确定 Realizes 关联在那里是否合适，从来没有想过返回一些实现它的东西）。在大多数情况下，他们不会跟踪产品。
考虑一个 Chef 类，它创建一个 Meal 对象。厨师将餐食归还给顾客班级后是否会对其进行跟踪？不，他要去吃下一顿饭了。因此，Chef 和 Meal 之间没有关联。
是的，确实，厨师在制作一顿饭时暂时拥有一顿饭，但饭菜并不是厨师的结构部分。他只制作餐食并将其交给消费者。对象图显示对象的结构，而不是对象的方法的作用。这是一种不同类型的图，例如活动图。
至于您的命令模式问题，调用程序取决于接口，而不是命令对象本身。由于 Invoker 仅依赖于接口，因此您可以向其传递实现该接口的任何类型的对象。它甚至不必是命令，只要它假装是命令即可。
调用者不知道它在调用什么，因此没有依赖性，也没有关联。举个例子，假设有人蒙住你的眼睛，并要求你识别他们给你的一个物体。您可能能够辨别出许多物体是什么，但有些物体您可能无法辨别。例如，您可能不知道面包面团和橡皮泥之间的区别，或者大橙子和小葡萄柚之间的区别。出于所有意图和目的，大橙子和小葡萄柚实现相同的触觉界面，但当您执行它们（吃它们）时，它们会产生不同的结果。
You're confusing structure with behavior.
An association implies a structural dependency, typically a "has a" relationship. A has a B. However, this is more like "Bill has a finger" rather than "Bill has a wallet". Bill may sometimes have a wallet, but that is not something structurally defining bill as a Human Being.
Does Creator have a product? No, not structurally. Neither does Concreate Creator. They instantiate a Product and then return it (I'm not sure a Realizes association is appropriate there, never thought of returning something as realizing it). They do not keep track of the Product in most cases.
Consider a class Chef, that creates a Meal object. Does the Chef keep track of the meal after he's returned it to Customer class? No, he's on to the next meal. Therefore, no association between Chef and Meal.
Yes, it's true that a Chef owns a meal temporarily as he's making it, but the meal is not a structural part of the chef. He only constructs the Meal and hands it of to the consumer. Object diagrams show structure of the objects, not what the methods of the objects do. That's a different kind of diagram, such as an Activity diagram.
As for your Command pattern question, Invoker depends on the Interface, not the Command object itself. Because Invoker depends only on an interface, you can pass it any kind of object that implements the interface. It doesn't have to be a command even, so long as it pretends to be one.
Invoker doesn't know what it's invoking, so no dependency and no association. As an example, consider that someone blindfolds you, and asks you to identify an object they give you. You might be able to tell what many objects are, but some you might not. For example, you might not know the difference between bread dough and playdough, or a large orange and a small grapefruit. For all intents and purposes, a large orange and a small grapefruit implement the same tactile interface, but they produce different results when you execute them (eat them).