oop - 两个 child 类(class)是否可以一起工作

Question

我有一个名为 Product 的基类。 “Drink”和“Pizza”类是从“Product”类继承的子类。我还有一个名为“Ingredient”的类，它是 Pizza 类的一部分，因此 Pizza 类应该有一个 Ingredient 类的实例(列表)。

我的问题是:由于 Ingredient 与所有其他“Products”具有相同的属性，它是否也可以继承“Product”类并与“Pizza”子类一起工作？

Answer 1

是的，他们可以!

是的，从同一个父类(super class)继承的类可以完美地协同工作。没有不兼容。甚至还有一种设计模式在同一类上使用这两种关系(composite pattern)。

备注:“一起工作”这个词有些含糊不清，可能意味着不同的东西。但是您的类图足够精确，表明您的意思是可能的关联。

但是如何呢？

您的图表显示了 Pizza 之间的可导航关联和 Ingredient (空心箭头)。这意味着实现应确保比萨饼可以轻松找到其配料。

在您的叙述中，您提到了一个列表。我知道 Ingredient可以没有任何 Pizza 存在，但是 Pizza 可以有多个 Ingredient .通过指示 * 在图表上指定此多重性很重要在 Ingredient 上协会方面。

相反方向的关系还有一些谜团:

• 未指定适航性:我们不知道 Ingredient应该能够轻松找到相关的比萨饼，或者如果这不相关。您可以使用相反方向的箭头(可导航)或跨线的 X(不可导航)进一步指定。您有权不指定并稍后决定。可导航性对类协同工作的方式有影响:这意味着 Pizza可以“使用”配料(例如，将其用作操作中的参数，直接调用配料操作等)。但是在相反的方向没有通航能力意味着 Ingredient无法单独发起与其比萨饼的合作。
• 更重要的是多样性:我们不知道一种成分是否只与一个比萨饼相关 (0..1)，或者它是否可以在多个披萨之间共享 (0..*)。了解这一点非常重要，因为实现会非常不同(在后一种情况下，您将拥有多对多关联)。

过度概括？

当发现 OOP 时，继承是很诱人的。然而，继承有很多含义、限制和后果。因此，请明智地使用它。

一个有用的建议是开始考虑 A 继承自 B，前提是 A 是更特殊的 B，或者相反，B 是 A 的更一般化。仅因为某些属性或操作共享而使用继承是危险的同名。顺便说一句，名称可能会产生误导。

在您的情况下，我理解 Product作为公司以给定价格出售的东西:Drink , Pizza , 也许 Antipasti或 Pasta .显示的价格是客户要求的价格。因此，我想知道是否 Ingredient被卖给客户。一种成分可能有价格，但它是购买价格。购买价格与销售价格不同:想象一家餐厅将分包一些非常特别的比萨饼:销售价格将与购买价格不同。

当然，如果您的 Product是比较笼统的东​​西，商业意义上的，如果能有销售价和采购价，不一定在菜单上，那没问题，可以。但请注意，此类通用产品的管理要复杂得多(例如，这里有一个著名的 ERP example 有 20 多个不同的屏幕来管理产品的所有方面)。

其他备注

一个很常见的建议是prefer composition over inheritance .这个经验法则旨在提醒我们在使用继承之前三思而后行。让我们明确一点，以防万一:这并不意味着继承和组合不兼容。