Question

我想知道UML中的关联，依赖关系和这种关系是如何继承的（或者说，一般来说）。所以，在这种情况下：

  ┌──────────┐                                        ┌──────────┐
  │  ClassA  │                                        │  ClassB  │
  ├──────────┤                                        ├──────────┤
  │          │─────────"One kind of relation"────────>│          │
  ├──────────┤                                        ├──────────┤
  │          │                                        │          │
  └──────────┘                                        └──────────┘
        ^
       /┬\
        │
        │
        │
        │
  ┌─────┴────┐
  │  ClassC  │
  ├──────────┤
  │          │
  ├──────────┤
  │          │
  └──────────┘

注意：

ClassA-ClassC属于泛化关系，箭头是实心的
ClassA-ClassB属于[依赖关系，关联，聚合，组合]
Unicode很酷，但使用编辑器字体看起来好多了：）

我的问题是，这些关系如何继承？例如，当ClassA依赖于ClassB时，ClassC是否依赖于ClassB？等

谢谢。

Answer 1

简单的答案是肯定的（出于最实际的目的，你不应该超越它）。

但问题比它看起来更复杂;引用统一建模语言参考手册，第二版：

单词 generalization 和继承经常互换使用，但也有实际上两个相关但不同概念。概括是一个建模之间的分类关系元素。它描述了一个元素是。继承是一种组合共享增量的机制描述形成一个完整的元素的描述。多数情况面向对象的系统，继承是基于概括，但继承可以基于其他概念，例如代表团自我语言的指针。立足上的继承机制泛化关系使保理和分享描述和多态行为。这是大多数面向对象的方法语言和UML。但请记住还有其他方法可能已被采取，那是一些编程语言使用。

我记得2003年的一个很长的讲座，关于泛化和继承之间的区别。简而言之，这两个概念属于不同层次的软件设计，或者引用Martin Fowler的UML Distilled，第三版，“各种建模视角”：

从概念上讲，我们可以说a 企业客户是其子类型客户如果是企业的所有实例顾客也是，顾名思义，客户的实例。公司客户是一种特殊的顾客。

概括的概念属于概念设计层面。

但是继承是一个属于实现角度的概念：

从软件角度来看，明显的解释是继承：企业客户是子类顾客。在主流OO中语言，子类继承所有超类的特征和可能覆盖任何超类方法。

我记得一个例子，其中泛化和继承之间的区别真正有意义：

正方形是一个矩形。这来自他们在数学中的定义：

矩形是四边形，有四个直角
正方形是具有四个相等边和角度的多边形

在设计层面，正方形和矩形之间存在泛化关系。

但在实施层面，情况有所不同：

矩形可以通过两种方法定义：宽度和高度
一个正方形可以由一个度量定义，因为所有边都相等

继承Square类中Rectangle类的宽度和高度会适得其反，这需要额外的约束来确保为宽度的setter和高度的setter提供相同的值。 p>

这是一个案例（我承认有些尖锐），你不会在实现层面将泛化关系转换为继承的使用。

那是那些日子。

Answer 2

由于继承是“is-a”（没有双关语）关系，你可以把它读作“ClassC是ClassA，它知道ClassB”，所以：

例如，当ClassA依赖于ClassB时，ClassC是否依赖于ClassB？

- 是的：）

Answer 3

你不是在问一个UML问题，而是在问一个更普遍的问题。

继承是什么意思？

ClassC是ClassA的子类。在每种实现继承的编程语言中，ClassC都具有ClassA的所有功能。

在不支持继承的语言中，您必须通过确保ClassA的所有功能也是ClassC的一部分来创建正确继承的错觉。

这是继承的定义。永远和永远。即使在UML图中也是如此。

UML类图中的关系如何继承？

3 个答案: