为何同一设计模式的UML描述存在差异？应该以什么为可信参考标准？

核心结论 #

不存在所谓“唯一可信”的设计模式UML类图，不同资料的表述差异本质是作者的表述侧重、面向的编程语言、以及省略的辅助内容不同，没有对错之分，你可以按下面的方法理清差异：

• 先锚定设计模式的原始定义
  所有公开的设计模式表述都脱胎于GoF（四人帮）的《设计模式：可复用面向对象软件的基础》，先吃透这本书里对迭代器模式的核心定义：一共4个核心角色，抽象迭代器定义遍历接口、具体迭代器实现对应聚合的遍历逻辑、抽象聚合定义创建迭代器的接口、具体聚合实现对应迭代器的创建方法。把四个角色的核心职责搞懂，不管类图怎么画，你都能快速对应上每个模块的作用。
• 搞懂UML箭头差异的本质原因
  你看到的箭头不同，基本都是以下几个原因导致的：
  • 表述侧重不同：比如聚合和迭代器的关系，画成依赖是侧重“聚合仅在创建迭代器时依赖迭代器接口”，画成关联/组合是侧重“迭代器实例会绑定对应聚合的实例，甚至生命周期和聚合完全绑定”，两种都是合理的，对应不同的实现场景。
  • 面向的编程语言不同：比如抽象迭代器/聚合的继承关系，有的画成接口实现（虚线空心箭头），有的画成类继承（实线空心箭头），只是对应不同语言的习惯：Java生态常用接口定义抽象角色，C++生态常用抽象类，本质都是泛化关系，不影响模式逻辑。
  • 内容省略不同：有的类图会省略客户端角色、有的会省略非核心的辅助方法，看起来结构就会有差异，只要核心角色和核心方法存在就没问题。
• 用实操快速打通认知
  不用死记硬背类图，自己动手写一个最小可运行的迭代器模式实现：比如自己定义一个迭代器接口、实现一个遍历自定义列表的具体迭代器、再定义聚合接口和对应的具体聚合类，写完再回头对比不同的类图，你一眼就能看出每个箭头对应的是你代码里的哪层关系：比如你把迭代器做成聚合的内部类，那二者就是组合关系；如果你把迭代器做成独立类，聚合创建时传入自身实例给迭代器，那就是关联关系，不同的实现对应不同的UML表示，差异自然就通了。

设计模式是灵活的设计思路，不是固定的代码模板，UML只是辅助表述设计的工具，只要核心逻辑符合模式的设计目的，不同的表述都是合理的，不用过度纠结形式上的一致性。

内容的提问来源于stack exchange，提问作者philomath