类型或抽象的实现......优点和缺点

Question

我正在与我的Java程序员交谈，并遇到了一个新手问题，辩论，甚至可能是愚蠢的，不幸的是让我感到困惑。为了让我的问题变得可以理解，我将在这里给出一个简单的例子。请考虑以下情况：

我有一个汽车引擎。每个发动机都设计用于一种燃料（称为可燃物）。

在这类问题中，我创建了一个“Vehicle”类，它使用“Engine”作为类字段成员，因为每个引擎都有属性和行为。让我们假设汽车燃料容器是汽车发动机的一部分，因此，发动机知道如何燃料自身，并知道如何储存它。考虑到这些事情，我试图开发一个“引擎”类（如前所述），它具有这样的属性。问题基本上就是这个。当我想到以下内容时，我会产生疑问：

有几种类型的汽车发动机。不同的引擎具有相同的属性，但配置不同。假设引擎模型没有遭受多态性，我得到了两种不同类型的设计......

我称之为“模特A”：

这就是“模特B”：

请注意，模型A显示了具体的类“Engine”，而模型B显示了带有它的实现的抽象类“Engine”。 我的问题是不同类型的模型之间存在什么含义，优点和缺点。

程序员，分析师和数据库管理员总是指示我永远不要将数据绑定到编程代码中，并且永远不要限制重新编译的程序（反复编译），只有重新编译提供结果。

根据模型B，“引擎市场”和公司的变化将始终反映代码的变化。因此，这将导致创建一种新类型的引擎，它的“引擎”类的扩展，它的实现和编译。

然而，型号“A”表示难以为不同的车辆分配相同的发动机，例如，使用相同的型号。每个新引擎实例的创建等于另一个可能需要相同的设置。

我看到两种类型的模型都有正面和负面，但我不确定它们。这种情况向我证明，添加新类型的东西可能会导致糟糕的道路。

虽然我想明确发动机和汽车的例子，但我认为这种情况可以在其他地方看到。快速思考另一种例子...如果我们有一个“水果”类，其子类型为“橙色”，“葡萄”，“等等”。对于每个新的水果，我们必须重写程序并重新编译吗？这不会占用一个程序吗？

如果我对某些事情感到困惑，请将其客观化为答案。

Answer 1

如果不同的子类型需要不同的代码来处理它们，请将它们设为不同的子类。如果不同类型的区别仅在于一个或多个字段的值，并且您不必编写任何特殊代码来以不同方式处理任何这些值，那么只需将它们作为单个具体类的所有实例。

如果您现在不需要子类，但您担心将来可能会担心，请不要担心。如果您的需求发生变化，以便将来需要子类，那么无论如何您无需以其他方式更改代码，因此您无论如何都必须重新编译。

Answer 2

除非模型存在根本缺陷，否则除非提供上下文，否则没有任何积极或消极的话值得讨论。根据上下文，我的意思是一组要求。一组要求将使模型A成为理想的一个，而另一个要求将完全无效（对于B来说相同）。

在最一般的术语中，模型A的假设缺点是它模拟了一组具体的要求。即没有要求扩展设计。始终存在具有固定特性和功能的发动机。 要求必须明确要求此。

在某些实际情况中，这将是理想的模型。

在另一个假设中，可能有一系列发动机，一些由铝制成，另一些则具有不同的允许。其他人可能有插件＆＃39;用于连接基本型号中不需要的不同电子设备的端口。

在这种情况下，模型B是正确的方法（模型A将是一个糟糕的选择。）

因此，如果没有要求，很难进行非平凡的讨论。对业务领域的要求是驱动域模型最重要特征的因素，然后驱动软件和体系结构相关模型。

PS。

您的模型正在混合 volatile 状态（on和可能name) with type/structural attributes (可燃,容量等等。）

此外，在您描述问题时，需要考虑fuel container。但实际上，它不是引擎的一部分。它是一个aggregate（不是composite而是一个aggregate），一个附加到引擎，但不依赖于它。它可以独立于引擎进行更换，交换和/或销毁（反之亦然）。

意思是，发动机和燃料容器都有不同的生命周期，即使它们都连接到工作系统中。这也需要一个＆＃39;型号B＆＃39;系统类型，因为您可以拥有只能适应特定燃料容器型号的发动机专业化。

因此，fuel()方法更适合fuel container实体，而不是engine实体。

我的$ 0.02