为什么使用 UML 有不同的方法来描述相同的设计模式？信任什么？

Question

我发现同时学习设计模式和 UML 很困难，因为有不同的方式来描述相同的模式，这让我不确定什么是唯一的事实来源。

以迭代器模式为例，这里只是我在知名网站上看到的一些图表：

1 维基百科

https://en.wikipedia.org/wiki/Iterator_pattern

2 教程要点

https://www.tutorialspoint.com/design_pattern/iterator_pattern.htm

3 重构大师

https://refactoring.guru/design-patterns/iterator

4 OODESIGN

https://www.oodesign.com/iterator-pattern.html

5 HOWTODOINJAVA

https://howtodoinjava.com/design-patterns/behavioral/iterator-design-pattern/

最让我困惑的是箭头符号是如何用来描述这些类之间的关系的。有时它们是泛化，有时是接口实现，定向关联或依赖。连构图也用了……

我想知道什么是让我明白这一切的最佳方式。

Answer 1

一般来说，在查看设计模式的 UML 模型时需要非常小心。原因有以下三个：

• 设计模式的参考是GoF。这本书出版于 1995 年，当时 UML 还没有出现，并使用了 OMT 表示法（UML 的祖先）的一种变体。如有疑问，这是值得信赖的来源。
• Java 语言设计于 1995 年公开，JDK 1.0 于 1996 年 1 月发布，该语言尚未广为人知。作者将他们的设计和代码示例基于 C++ 类模型，即仅基于类和继承，而无需考虑多重继承。大多数现代语言不支持多重继承。因此，一些原始模式必须适用于 Java、C# 或 Swift，以区分类、抽象类和接口，以及继承和接口实现。有多种方法可以做到这一点。例如，一些系统地将抽象类转换为接口。有些人只有在发生冲突时才皈依他们。还有一些根据界面“精神”进行转换。
• 发生了误解。有些人在网上发布了这样的图表，但误解了模式，或者误解了 UML，或者两者兼而有之。此外，Gamma 等人在他们还是博士生时就开始了这本书，也犯了一些错误。例如，您会发现他们在使用 OMT 聚合时存在一些不一致之处。
• 最坏的情况是 Builder 模式，您不仅会遇到这些问题，而且还有命名冲突：一本非常流行的 Java 书籍介绍了 builder 模式的（非常不同的）变体，具有不同的意图和另一种设计，导致完全混乱。

现在到您的具体示例，并根据您提供的内容：

• oodesign 是最接近原始模式且完全准确的。顺便说一句，当涉及到模式时，我主要使用指向他们页面的链接。
• 重构大师也是不错的选择。他们选择使用接口而不是抽象类，这很好。但是他们重新定义了界面的操作和属性（可能与自己的示例有关）并且需要双向导航，这似乎是不合理的。如果您有兴趣，有一个“Head First: Design patterns”，它使用类似的映射但保留了原始界面。
• wikipedia 也不错：他们忽略了客户端（GoF 以浅灰色显示，表明它对于这种模式不是必需的）；它们在依赖关系上更加精确和完整；但他们也以不同的方式重新定义了操作和属性。他们添加了一个不必要的聚合符号。
• 如何在 Java 中实现 令人困惑，因为他们保留了一个抽象类并为另一个选择了接口。他们隐藏了操作和属性。但乍一看并没有什么根本错误。
• 忘记教程点，至少对于这个 UML 图。这完全是错误的，正如 cmets 中已经提到的 @qwerty_so。

准确性声明仅适用于此模式和当前版本的内容。鉴于我的介绍性评论，这不能推广到所有设计模式。