将引用/关联重构为继承

Question

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

UML图描述了我程序的当前工作状态。实际的代码结构更加复杂，因此请原谅此虚构示例。

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

soldComupter.ReferenceComputerType.CPU

是否可以用继承替换关联？删除ReferenceComputerType并从ComputerType继承SoldComputer。呼叫看起来像这样：

soldComupter.CPU

目标不是通过装饰器模式伪装引用，而是通过继承取消对所有字段和功能的扫描。

我遇到的问题是，多台出售的计算机可以引用同一计算机类型。所以我不能将现有的computerType转换为soldComputer，因为这两个列表必须同时存在于真实应用程序中。

Answer 1

  

是否可以用继承替换关联？

否，不可能。

@ThomasKilian指出，“计算机不是计算机类型”，或更笼统地说， 产品不是产品类型 。

您的模型似乎合理。

在业务应用程序中很常见的是，既有一个针对产品类型的类，又有一个针对单个产品的类，因此，这两个类是相关联的，用于表示产品所具有的信息。

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

Answer 2

如果我正确理解您的推理，则您的市场出售SoldComputer，并根据通用ComputerType分类。此外，ComputerType预定义了该类型所有计算机的某些特征。

关于继承的构成

首先，Computer不是ComputerType。但是，从这些类的属性来看，我的论点似乎只是关于命名问题，因为您的ComputerType也可以命名为GenericComputer，在这种情况下，它的影响就较小。

但是您的ComputerType只是问题的一小部分。因为迟早您会意识到，一台出售的计算机还可以具有一些StorageType（例如HDD，1To）以及一些GraphicType以及许多其他可配置选项。明天，您甚至可能会拥有甚至不知道的新型组件（例如，全息投影仪2D / 3D），但从根本上说，它们不会改变您对SoldCompter进行描述和分类的方式。

这就是为什么您应该选择 composition over inheritance 的原因：您可以与其他类型的组件关联。当前方法的最大优点是，如果用户决定扩展其SoldComputer的RAM，则他/她可以只选择匹配的ComputerType，一切都很好。

如果要继承，则SoldComputer将具有其CPU和其memory：如果用户更改其值，则将与分类不一致。也许没有对应于新类别的计算机类型...

替代

解决问题的另一种方法是使用类Computer，其中包含所有专门描述计算机的字段（例如CPU，内存，磁盘等）：

• 市场上的计算机类型集将填充Computer，但仅填充一些相关字段。
• 市场上出售的计算机集中将填充Computer，其中有一些所有者。

创建要出售的新Computer可以使用prototype design pattern。但是，一旦完成，计算机与原型之间就不再存在任何关系。

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