产品、产品bundle及其"Purchased"版本的类结构

Question

我有一对现有的业务对象类型，Product和PurchasedProduct，后者是前者的子类。

前者表示客户购物篮中的一个对象，所有信息(数量除外(都是从存储在数据库中的"原型"产品中读取的。

当客户结账时，购物篮的内容以其原型的ID存储在数据库中，但所有相关的潜在可变购买信息(净价，增值税税率，数量等(都"烘焙"到记录中。这样，当客户检查其订单历史记录时，每个订单将创建一个 PurchasedProduct 对象，该对象将报告结帐时的值，而不是原型值。

因此，在检索购买的产品实例时，可以先读取原型以填充大部分数据(因为PurchasedProduct是Product(，然后读取购买的实例以填充结帐时的值。

现在客户希望拥有产品"捆绑"。它们在所有方面都与单个"产品"相同，但以下情况除外：

1( 捆绑包包含Product对象列表(数量固定(，但将有自己的价格与所包含的产品无关，它自己的数量等。2(购买时，不仅需要记录自己的结账时间价格等，还需要记录其组成产品的价格

我最初的想法是：

ProductBundle : Product
{
    public List<Product> Products { get; set; }
    // other stuff as needed
}
PurchasedProductBundle : PurchasedProduct
{
    public List<PurchasedProduct> Products { get; set; }
    // other stuff as needed
}

这似乎给主要负责将产品 ID 转换为业务对象的ProductRepository增加了很多复杂性。它需要检查传入的数据，并在这四种类型中的每一种路径之间切换，其中某些路径具有重复的功能。它似乎也复制了子产品列表属性。最后，PurchasedProductBundle既是ProductBundle又是PurchasedProduct，但当然，C#没有多重继承。

另一种路由可能是组合，因此ProductBundle是单个Product和Product列表的组合，但这似乎是通过基础Product传递属性访问的很多样板。

这些是明智的路线，还是我缺少一些非常整洁的模式？

Answer 1

一种可能性是认为PurchasedProduct不是"从Product派生出来的"。而是具有IProduct界面，该界面要么是PurchasedProduct，要么是Product。您的产品捆绑包将是IProductBundle的(IProduct(，并为PurchasedProductBundle和ProductBundle提供IEnumerable<IProduct> Products { get; set; }。

这背后的原因是PurchasedProduct不是Product，它更像是购买或订单线而不是Product，并且更改价格的原因可能很多，不仅价格会随着时间的推移而变化，而且可能会有商业报价，优惠券。

另一种可能性是考虑您根本不介意捆绑包中包含的产品的价格是多少？ 毕竟，您可能会在全球范围内宣传回扣百分比，但这是另一个问题。