我正在尝试对具有一组综合属性的产品进行建模。通常，在线商店会使用文本描述来列出特定产品的属性。然而，这个解决方案不是最优的。
例如，以下链接显示同一产品的文本描述中的属性不一致，但制造商不同:
因此，我选择了如下继承层次结构:
Product > Component > GraphicsCard > NvidiaGraphicsCard这样做的原因是因为我希望对每个
Product 的属性进行细粒度控制。 .这允许我包含特定于说 NvidiaGraphicsCard 的属性。不适用于 ATiGraphicsCard .请注意，除了向子类添加更多字段之外，继承还允许我在拥有
OrderItem 方面利用多态性。持有对 Product 的引用.这就是我排除作曲的原因。拥有如此深的继承层次是否有问题，如果有，是否有任何解决方案或模式来处理这个问题？
最佳答案
由于几个原因，在 DDD 和 ORM 的上下文中，深层继承层次结构存在问题。当您尝试定义实体的身份时，就会出现一个问题。一个 Product必须基于身份与其他产品进行比较，无论是在比较哪个子类。此功能可以在 Product 中提供。类，但必须注意确保子类也可以进行比较，并且存在一些问题。例如，NHibernate 会为类生成一个代理，这样对象的实际运行时类型就不会是 NvidiaGraphicsCard。但是从它继承的代理。而 NvidiaGraphicsCard 的 transient 实例不会是代理。这意味着您无法根据类型比较它们。
另一个困难是配置 ORM 映射以支持继承。虽然大多数 ORM 都允许这样做，但生成的映射和生成的 SQL 通常很复杂。您是否将所有子类存储在一个表中？在具有通用产品表外键的多个表中？在前者中，您最终会得到一张巨大的 table 。在后一种情况下，您的查询将受到影响，因为所有子类表都需要连接。关系模型和对象模型之间存在太多的阻抗不匹配。事件如果使用文档数据库，最好支持组合而不是继承。
相反，我会选择一个 Product类，它可以由特定于产品的描述符或属性字典组成。这将是 OrderItem引用 Product不知 Prop 体的产品类型——不需要多态性。这也将更容易允许新类型的产品 - 无需创建新的子类。
关于oop - 深度继承层次结构的替代方案？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/12846939/