两个子班可以一起工作吗

Question

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

我的问题是： 由于成分与所有其他“产品”具有相同的属性，它是否也可以在与“披萨”子类一起工作时从“产品”类继承？

Answer 1

是的，他们可以！

是的，从同一个超类继承的类可以完美地协同工作。没有不兼容。甚至还有一种设计模式在同一个类上使用这两种关系（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。这个经验法则旨在提醒我们在使用继承之前要三思而后行。让我们明确一点，以防万一：这并不意味着继承和组合不兼容。