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

时间:2011-11-03 00:02:10

标签: design-patterns uml

我或多或少清楚GOF模式是什么以及它们的行为方式。
但是,我觉得我错过了一些全局的东西(用UML或模式),因为如果我试图在脑海中重复这些,我会在许多GOF类图中画出一两个额外的箭头。我知道UML图不必显示所有连接,但为什么不是所有连接都在简洁的模式图中。

几个例子:

工厂方法UML图:
http://en.wikipedia.org/wiki/Factory_method_pattern

为什么没有从Creator到Product的关联线(纯实箭头)? FactoryMethod有一个注释:“product = FactoryMethod()”。这意味着Creator会跟踪产品。为什么UML中没有连接?

命令模式UML图:
http://en.wikipedia.org/wiki/Command_pattern

为什么祈求者是孤儿?客户端与Receiver关联,依赖于Concrete命令,但它需要将命令传递给Invoker。为什么Client和Invoker之间没有连接?

感谢您的回答。

1 个答案:

答案 0 :(得分:1)

你的结构与行为混淆。

关联意味着结构依赖,通常是“有”关系。 A有B.但是,这更像是“比尔有手指”,而不是“比尔有钱包”。比尔有时可能有一个钱包,但这不是结构上将人民币定义为人类的东西。

创作者有产品吗?不,不是结构上的。 Concreate Creator也不是。他们实例化一个产品然后返回它(我不确定一个Realizes关联在那里是合适的,从来没有想过返回一些东西就像意识到它)。在大多数情况下,他们不会跟踪产品。

考虑一个类Chef,它创建一个Meal对象。厨师在将其送回客户课程后是否记录下餐点?不,他正在吃下一顿饭。因此,Chef和Meal之间没有关联。

是的,一位厨师在他做饭时暂时拥有一顿饭,但这顿饭不是厨师的结构性部分。他只构建膳食并将其交给消费者。对象图显示了对象的结构,而不是对象的方法。这是一种不同的图表,例如活动图。

至于你的Command模式问题,Invoker依赖于Interface,而不是Command对象本身。因为Invoker只依赖于接口,所以可以传递任何实现接口的对象。它甚至不必是一个命令,只要它假装是一个。

Invoker不知道它在调用什么,所以没有依赖关系,也没有关联。例如,考虑有人蒙蔽你的眼睛,并要求你识别他们给你的对象。您可能能够分辨出许多对象,但有些可能不是。例如,您可能不知道面包面团和橡皮泥,或大橙子和小葡萄柚之间的区别。出于所有意图和目的,大橙子和小葡萄柚实现相同的触觉界面,但是当你执行它们时会产生不同的结果(吃它们)。