DDD领域驱动设计批评文集
做强化自测题获得“软件方法建模师”称号
《软件方法》各章合集
8.3 建模步骤C-2 识别类的关系
8.3.4 识别关联关系
8.3.4.4 类关系再整理
有了前面的知识，我们需要再整理一下类的关系。用类图表示类的关系如图8-134。
图8-134 “类的关系”各概念之间的关系
从图8-134可以看到，泛化、关联和依赖在一个抽象级别，普通关联和聚合在一个抽象级别，共享聚合和组合（即独占聚合）在一个抽象级别。因此，我们在表达的时候要注意，说“泛化和关联”可以，但说“泛化和聚合”、“泛化和组合”或“继承和组合”是不合适的。
本书的观点是取消“共享聚合”的概念，将其合并到“普通关联”中。此时，“组合”就等同于“聚合”，于是，“聚合”的概念也可以取消，得到图8-135。
图8-135 本书观点的类关系
8.3.4.5 和《设计模式》用语的区别
GoF所写的”Design Patterns: Elements of Reusable Object-Oriented Software”（《设计模式》），第1章中有一句被广为流传的话：
Favor object composition over class inheritance.
优先使用对象组合而不是类继承。
这句话常让人误解组合和继承是一个级别的，其实，根据GoF《设计模式》的用词，这句话中的“组合”应该近似于UML中的“关联”。
如图8-136，在GoF《设计模式》中，给出这句话之后，作者接下来讨论了aggregation（聚合）和acquaintance（认识）的区别，并且说acquaintance有时也被称为association（关联）或using（使用）。然而，在后面的内容中，作者把这几个词全部抛弃，一律使用composition。
图8-136 摘自Design Patterns: Elements of Reusable Object-Oriented Software, Erich Gamma , et al. ， 1995
根据GoF书中内容猜测，其中用语和UML以及本书的用语的对应关系可能如图8-137，图中我用相同颜色标出对应用语。
图8-137 《设计模式》、UML和本书用语的对应
以上仅属推测，而且书中的叙述也是有矛盾的，例如这一句：
Consider the distinction between object aggregation and acquaintance and how differently they manifest themselves at compile- and run-times.
考虑对象聚合和认识之间的区别，以及它们在编译时和运行时如何不同地展现自己。
这句话好像是在说“聚合”和“认识”在编译时和运行时有所不同，这和图8-131中的对应③和④矛盾。
另外，图8-136的片段中，把association（关联）和using（使用）说成同一个意思，这个也是让人困惑的。using听起来更像是UML话语中的“依赖”。
