什么是阶级关系？

Question

其中包括：

Motorized Vehicle，Car，Motor，Truck

我在考虑以下事项：

a Car is a Motorized Vehicle，a Car has a Motor，a Truck has a Motor，a Truck is a Motorized Vehicle

Q1：我在上述关系中是否正确？

Q2：我们现在想要关联fan这个词......看起来怎么样？

我的尝试： a fan has a motor，a Motorized Vehicle has a motor，a Car is a Motorized Vehicle，a Car has a Motor，a Truck has a Motor，a Truck is a Motorized Vehicle

我需要澄清一下......

Answer 1

这可以很好地解决上述问题。由于电动机可以在带有新电动机的汽车中更换，因此您可以保持聚合代替组成。请参考下面的图片

Answer 2

[汽车，卡车]＆＃34;是＆＃34; [机动车辆]＆＃34;有一个＆＃34; [马达，风扇]

Answer 3

我认为没有上下文，你的问题没有100％准确的答案。

例如，要在我们的上下文中分离卡车和汽车，我们应该能够确定汽车和卡车的行为方式不同

如果汽车和卡车只是简单的容器（例如）“名称”和“质量”，或者所有者等在应用程序中具有完全相同的行为，那么我们可以根据特定对象而不是类来考虑这可以促使我们用两个实例来实现Vehicle（或仅仅是机动车辆）类

Vehicle car = new Vehicle("Car",1200,someMotor);
Vehicle truck = new Vehicle("Truck",3400,someMotor);

仅使用“术语”这很简单，但是上下文也存在关系问题。通过关系我的意思是连接。几乎可以肯定，Motorized vehicle会有一个Motor（但也可能有更多的那个），但这是一个很大的机会，“马达有车”（作为车主，特别是在数据库实体的背景下，特别是如果我们的背景比汽车更集中于电机 - 例如当我们为汽车经销商建造系统时。）

对于每个人来说，还有另外一件小事情不是那么清楚，不仅“汽车有电机”而“卡车有电机”，更像是“机动车有电机”，所以汽车没有电机仅仅因为“汽车有电机”，但“因为它是机动车！”。

此外，进入细节（问题是oop标记），在面向对象的术语中我们应该考虑类 vs 接口，我们最终可以得出结论，如果我们的环境（像大多数人一样）不允许多重继承，MotorizedVehicle更多的是接口（我们可以从中得到一个电机）。这将使我们无法解决诸如“奥巴马的车应该同时MotorizedVehicle和ArmoredVehicle之类的问题，但我在不同的阶级机构中有机动/装甲”。

TL; DR全部取决于上下文，更喜欢组合和界面而不是复杂的类层次结构