Delphi 重构对继承的引用/关联

在下面的示例中，如何将关联重构/重写为继承

UML图描述了我的程序的当前工作状态。真正的代码结构更复杂，所以请原谅这个虚构的例子

有一个市场最初在列表中包含一些计算机类型。出售计算机时，将创建一个新的对象SoldComputer并将其添加到第二个列表中。售出的计算机引用了该计算机类型。出售的第一台计算机的CPU可通过以下方式调用：

soldcomopter.ReferenceComputerType.CPU

是否可以用继承替换关联？正在删除引用ComputerType并从ComputerType继承SoldComputer。电话如下所示：

soldComupter.CPU

目标不是通过装饰器模式来伪装引用，而是通过继承来描述所有字段和功能

我面临的问题是，多台售出的计算机可以引用相同的计算机类型。因此，我无法将现有的computerType类型转换为soldComputer，因为在实际应用程序中，两个列表必须同时存在

是否可以用继承替换关联

不，不可能

正如@ThomasKilian所指出的，“计算机不是计算机类型”，或者更一般地说，产品不是产品类型

你的模型似乎很合理

在商业应用程序中，一个类用于产品类型，另一个类用于单个产品，这是非常常见的，因此这两个类关联用于表示产品所具有的类型的信息

---

为什么您要使用继承/子类关系呢？

如果我正确理解您的推理，您的市场销售的

SoldComputer

，它们根据通用

计算机类型进行分类。此外，
ComputerType
预先定义了该类型所有计算机的某些特征

组合重于继承
首先，
计算机
不是
计算机类型
。但从这些类的属性来看，我的论点似乎只是关于命名问题，因为您的
ComputerType
也可以命名为
GenericComputer
，在这种情况下，它就不那么令人震惊了

但是您的
计算机类型
只是问题的一小部分。因为你迟早会意识到，一台售出的计算机也可能有一些
存储类型
（例如HDD，1To），也可能有一些
图形类型
，以及许多其他可配置选项。明天，你甚至可能会有一些你甚至不知道的新型组件（例如全息光束器2D/3D），但这从根本上不会改变你描述和分类
SoldComputer
的方式

这就是为什么您更喜欢：您可以与其他类型的组件关联。当前方法的最大优点是，如果用户决定扩展其
SoldComputer
的RAM，他/她可以只选择匹配的
计算机类型
，一切正常

如果您选择继承，
SoldComputer
将拥有其
CPU
和
内存
：如果用户更改其值，则与分类不一致。也许没有对应于新分类的共话者类型

可供替代的
另一种看待问题的方法是让一个类
Computer
包含所有技术上描述计算机的字段（例如CPU、内存、磁盘等）：


市场上的计算机类型集将填充
计算机
，但只填充一些相关字段
市场上出售的一套计算机将由拥有某些所有者的
计算机填充

创建要出售的新
计算机可以使用。但一旦完成，计算机和原型之间就不再有任何关系

在这种情况下，市场将不再按计算机类型分类。搜索将始终是动态的（最终使用原型的选择列表初始化）。

那应该是什么？如果一个类继承了它是一个子类。那么
SoldComputer
就变成了
市场
。在我看来，这完全是胡说八道。
SoldComputer
应该继承自
ComputerType
，所以它应该成为
ComputerType
而不是
市场
。是的
SoldComputer
应该是这样的e是
ComputerType
的一个子类。我想在这个例子中，
SoldComputer
应该是
ComputerType
会让人困惑。我现在有了一个更好的例子。如果基本问题仍然是相同的，可以重写问题的解释吗？是的，你可以（也应该）编辑您的问题以澄清问题。但是，计算机不是计算机类型。它有计算机类型。为什么要“将现有计算机类型转换为soldComputer？”？你能详细说明为什么不可能吗？因为根据UML规范，用泛化替换导航关联是完全有效的。但也许你只是说不应该这样做？@Christophe：你从哪里读到用泛化替换关联是有效的？这两种类型的r类之间的关系具有完全不同的语义。这根本不是我说的。我说的是，如果你要替换关系，图表将是有效的：它只是意味着完全不同的东西。这就是OP提出问题的原因：更改后的意思是否更接近他/她想要表达的意思。@Christophe:这正是你所说的。只要阅读你之前的评论，你说“根据UML规范，它将是pe