从图8-108可以看到，泛化、关联和依赖在一个抽象级别，普通关联、聚合和组合在一个抽象级别。
我们表述的时候要注意，说“泛化和关联”可以，但说“泛化和聚合”、“泛化和组合”或“继承和组合”是不合适的。
因《设计模式》产生的误解
GoF《设计模式》第1章中有一句被广为流传的话：
Favor object composition over class inheritance.
优先使用对象组合而不是类继承。
这句话常让人误解组合和继承是一个级别的，其实，根据GoF《设计模式》的用词，这句话中的“组合”应该近似于UML中的“关联”。
如图8-109，在GoF《设计模式》中，给出这句话之后，作者接下来讨论了aggregation（聚合）和acquaintance（认识）的区别，并且说acquaintance有时也被称为association（关联）或using（使用）。然而，在后面的内容中，作者把这几个词全部抛弃，一律使用composition。
图8-109 摘自Design Patterns: Elements of Reusable Object-Oriented Software, GammaE , et al. ， 1995
根据GoF《设计模式》书中内容猜测，其中用词和UML以及本书的用词的对应关系可能如图8-110。左右对应为：①继承=泛化；②组合≈关联；③认识≈普通关联；④聚合≈聚合 组合。
图8-110 《设计模式》话语和UML话语中的对应
以上仅属推测，而且书中的叙述也是有矛盾的，例如这一句：
Consider the distinction between object aggregation and acquaintance andhow differently they manifest themselves at compile- and run-times.
考虑对象聚合和认识之间的区别，以及它们在编译时和运行时如何不同地展现自己。
这句话好像是在说“聚合”和“认识”在编译时和运行时有所不同，这和图8-110中的对应③和④矛盾。
另外，图8-109的片段中，把association（关联）和using（使用）说成同一个意思，这个也是让人困惑的。using听起来更像是UML话语中的“依赖”。
未咨询作者，网络搜索也没有查到有价值的信息，如果有读者对此有更深入的了解，请不吝指正。
8.3.3.2 聚合/组合
聚合/组合考虑的出发点是责任分配
两个类之间存在聚合/组合的关联，意味着这两个类的对象之间存在整体和部分的关系。在图形表示中，菱形一端的类代表整体，另一端代表部分。
划分出整体-部分的特殊关联，考虑的出发点是责任分配。通过建立聚合/组合，使整体把部分封闭起来。在责任分配时，不管外部对象想要发消息给聚合/组合结构里的哪一个对象，都应该先把消息发给整体对象，再由整体对象分解和分配给聚合/组合里的对象，如图8-111所示。
