在下面的例子中，如何将关联重构/重写为继承。x1c 0d1x
UML图描述了我的程序当前的工作状态。真实的的代码结构更复杂，所以请原谅这个虚构的例子。
有一个Market，它最初在一个列表中保存一些计算机类型。当一台计算机被出售时，会创建一个新对象SoldComputer并将其添加到第二个列表中。出售的计算机引用该计算机类型。第一台出售的计算机的CPU可以通过以下方式调用：soldComupter.ReferenceComputerType.CPU
是否可以用继承替换关联？删除ReferenceComputerType并从ComputerType继承SoldComputer。调用如下所示：soldComupter.CPU
我们的目标不是通过装饰器模式来掩饰引用，而是通过继承来描述所有的字段和功能。
我遇到的问题是，多台售出的计算机可以引用相同的计算机类型。所以我不能将现有的computerType类型转换为soldComputer，因为这两个列表必须同时存在于真实的应用程序中。
2条答案
按热度按时间jckbn6z71#
如果我没理解错的话，你的市场销售的
SoldComputer是按照通用的ComputerType来分类的，而且ComputerType预先定义了该类型所有计算机的一些特性。组合优于继承
首先，
Computer不是ComputerType。但是查看这些类的属性，似乎我的论点只是关于命名问题，因为您的ComputerType也可以命名为GenericComputer，在这种情况下，它不会那么令人震惊。但是你的
ComputerType只是问题的一小部分，因为迟早你会意识到一台出售的电脑也可以有一些StorageType（例如HDD、1 To），可能还有一些GraphicType，以及许多其他可配置选项。你甚至可能有你甚至没有意识到的新型组件（例如全息投影仪2D/3D），但这从根本上不会改变你描述和分类SoldCompter的方式。这就是为什么您应该首选**composition over inheritance**：您可以与其他类型的组件关联。您当前方法的最大优点是，如果用户决定扩展其
SoldComputer的RAM，他/她可以选择匹配的ComputerType，一切都很好。如果你选择继承，
SoldComputer将有它的CPU和它的memory：如果用户改变了他们的值，它将与分类不一致。也许没有对应于新分类的copmuter类型...备选
另一种看待这个问题的方法是有一个类
Computer，其中包含所有在技术上描述计算机的字段（例如CPU，内存，磁盘等）：新的
Computer的创建可以使用prototype design pattern进行销售。但是一旦完成，计算机和原型之间就没有任何关系了。在这种情况下，市场将不再按计算机类型分类。搜索将始终是动态的（最终使用原型的选择列表进行初始化）。
gz5pxeao2#
是否可以用继承来代替关联？
不，这不可能。
正如@ThomasKilian所指出的，“计算机不是计算机类型”，或者更一般地说，产品不是产品类型。
你的模型似乎很合理。
在业务应用程序中，一个类用于产品类型，另一个类用于单个产品，这是非常常见的，因此这两个类相关联，用于表示产品具有的类型信息。
为什么要使用继承/子类关系？