GOF模式UML图中的相关性箭头

Question

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.

Answer 1

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).