对于UML类图,如果一个类A与另一个类B存在组合关系,那么它是否像继承一样工作?我知道类A不能没有类B,但是类A是否会继承类B的属性和方法?
对于UML类图,如果一个类A与另一个类B存在组合关系,那么它是否像继承一样工作?我知道类A不能没有类B,但是类A是否会继承类B的属性和方法?
在面向对象设计中,常见的建议是优先选择组合而非继承。这可能会让人误以为这两个不同的概念之间存在关系:
更加误导的是,通用的OO文献中所使用的“组合”通常对应于简单的UML关联,并且不能像UML“组合”那样被理解为具有限制性。
如果类D
从B
继承,这意味着D
特化了一个更一般的概念B
:
B
的所有属性和操作(无需在图表中重复),B
不相关的其他属性和操作,B
的一些操作。D
的任何对象在其整个生命周期中也是类B
的对象。这就是为什么我们谈论“是一个”关系的原因。天真的例子(仅用于说明):
如果类B
与C
“组合”(具有组合关联),这意味着B
对象可以在其生命周期内与不同的C
对象相关联。并且类C
的对象:
B
对象。这就是为什么我们有时会说“拥有”关系;B
对象。注意:UML组合是关于独占所有权的。在OO文献中,“组合”一词通常指没有任何所有权甚至排他性的较弱关联。
天真的例子(仅用于说明):
A继承B意味着A是一个B,这绝对不适用于A <*>--- B
或者A <*>---> B
或者反过来。
然后,无论操作的可见性如何,您都不能将A的操作应用于B的实例,反之亦然,除非您还有一个比组合更高的继承。
关于B的属性,根据组合的实现方式,它们可能是相应A实例的一部分,例如在C++中不使用指针进行组合时就是这种情况。但无论如何,这并不意味着B的这些属性是A的属性,要访问它们,首先需要通过组合访问B的实例,并且这也假设A的实例有权直接访问B的这些属性,因此它们通常是public的。
请注意,你可以拥有A<*>--->B<*>--->A
等等,幸运的是这意味着 A 继承了 B,而 B 继承了 A,这是不可能的。
Car
实际上是Chassis
,而只有整个结构才能被称为Car
。UML 对于展示这种结构的存在性实际上很差,经常导致混淆(关于聚合的问题)。 - qwerty_so