Java Has-A关系是否适用于继承的成员？

鉴于代码：

class Car{
   Engine engine;
}

class SportCar extends Car{
   SportChair chair;
}

说“SportCar有一个发动机和一把运动椅”是正确的吗？

---

或者，唯一有效的肯定是：“SportCar”有一个“SportChair”和“Car”有一个“引擎”？

如果一辆SportCar是一辆车，一辆车有一个引擎，在我看来，SportCar有一个引擎。完全有效。

视情况而定——我不会在UML图中复制这种关系，但从概念上讲，SportsCar有一个（n）引擎，因为它源于Car。

我对此没有任何明确的来源，但我的直觉是这种关系确实适用于继承的成员

在您的示例中，SportCar“是一辆”汽车，因此它“有一个”发动机

这可能与的有关，其中超级类型应可由其任何子类型替换。在这种情况下，超级类型的“has-a”引擎，为了使子类型遵循LSP，它们必须认识到它们也有一个引擎

这不仅适用于类的成员，也适用于一般的行为和状态——一个类不应从另一个类继承，除非继承的每个方面都有意义。也就是说，在您的示例中，如果Car有一个方法“attachBabySeat（）”，SportsCar从中继承就没有意义了。同样，受保护的BabySeat[]babySeats成员对跑车也没有意义

Java中的例外情况是

private

或“package private”（又名默认）成员变量。这些通常是实现细节，不是抽象的一部分。子类不能访问这些字段，所以我不认为私有成员是子类“HAS-A”关系的一部分。

---

就Java语言而言，创建子类时，也会构造超类（隐式或显式）。因此，当一个超类有一个私有成员时，它在内存、JVM等方面仍然是子类对象的一部分。例如，可以从该子类调用超类上使用私有成员的方法，而不会出现问题。所以在某种程度上，你可以说子类确实有超类的“一个”私有域，但我认为这是物理层次的，不是概念层次的，可以忽略不计。

是的，跑车是一辆汽车，因此有发动机。这是设计模式的一个示例

没有。说跑车有发动机是无效的。特别是在引擎具有默认访问权限的示例中。我想最好的方法是看下面的内容

我将使用一个真实世界的例子，我认为这通常会有所帮助

驼鹿是鹿的一种

鹿有两只眼睛，所以驼鹿有两只眼睛

受伤的麋鹿有一只眼睛

---

受伤的驼鹿是驼鹿的一种。

代码中有一个问题，因为它会暴露字段。如果

Car

是一个带有

getEngine

方法的接口，那么这种关系仍然成立。我的观点不是关于封装，跑车有一个引擎似乎是合乎逻辑的，但我想知道，从语言的角度来看，这样说是否有效。这个问题具体是关于包私有访问，如示例中所示？如果是那样或者是私有的，我会说不-子类关系不是“has-a”。对于公众/受保护的人，我会说是的。正如我所说的，这是我的直觉，不幸的是，我无法将任何信息来源归因于此。