1

其中条款：

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

我需要对此进行一些澄清......

4

3 回答 3

2

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

于 2014-04-01T12:10:41.360 回答
0

[汽车，卡车] “是” [机动车辆] “有” [电机，风扇]

于 2014-04-01T02:36:41.240 回答
0

我认为没有上下文就没有 100% 准确的回答您的问题。

例如，要在我们的上下文中区分卡车和汽车，我们应该明确能够分辨出汽车和卡车的行为不同。

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

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

仅使用“术语”就很简单，但是上下文也存在关系问题。我所说的关系是指联系。几乎可以肯定Motorized vehicle会有一个Motor（但请记住，也可以有更多），但这是一个很大的机会，即“汽车有车辆”（作为所有者，特别是在数据库实体的上下文中，特别是如果我们的上下文比车辆更集中于电机 - 例如当我们为汽车经销商构建系统时）。

还有一个小东西大家可能不太清楚，不只是“汽车有马达”和“卡车有马达”，更像是“机动车有马达”，所以汽车有马达不仅仅是因为“汽车有马达”，但“因为它是机动车辆！”。

此外，深入细节（因为问题是 oop 标记的），在面向对象的术语中，我们应该考虑类与接口，我们可以得出结论，这MotorizedVehicle更像是接口（我们可以从中获得电机）而不是类 - 如果我们的环境（像大多数环境一样）不允许多重继承。这将防止我们出现诸如“奥巴马的汽车应该两者兼而有之MotorizedVehicle，ArmoredVehicle但我已经在不同的班级中进行了机动/装甲”之类的问题。

TL;DR 都依赖于上下文，更喜欢组合和接口而不是复杂的类层次结构

于 2014-04-01T12:26:04.277 回答