0

我需要一些关于如何为这个简单的分类（？）示例建模的建议：
我有一个产品。一个产品可以有不同的类型，例如 ProductType 1、ProductType 2 和 ProductType 3。所有产品都有一个部件号和一个名称。它们的不同之处在于它们的价格计算方式。

  • 类型 1 的产品价格取决于产品的数量。所以如果我有 5 个产品，价格是 $x。如果我有 20 个产品，价格是 $y，以此类推。
  • 类型 2 的产品价格取决于每个产品的重量。如果重量为 5 公斤，则价格为 $x，以此类推。
  • 类型 3 中的产品具有简单的价格，例如每件产品的价格为 $x。

在我看来，每个“价格结构”都需要有一个专用的表/类。然后，产品将参考其价格结构，具体取决于产品的类型。您是只创建一个“产品类型”表并在 Product 类上有一个名为 Type 的属性，还是使用泛化，因此 Product 1/2/3 是 Product 的子类型？将有 5 种不同的价格结构，并且价格的计算方式因每种类型而异。因此，计算订单总价的逻辑取决于每种产品类型。

你能给我一些关于如何以最佳方式建模的建议吗？如果我选择 Product 类上有一个 Type 属性的方法，我想我会在我的代码中得到很多 if-else 语句。如果我选择对它们进行子类化，每个类都可以负责计算正确的价格，或者它被要求做的任何事情。

4

2 回答 2

1

我的建议是，在您的关系数据模型中，您将有类型列来区分记录类型。在代码中，您绝对应该使用子类化。域模型应尽可能独立于底层数据模型，并且您的描述很好地支持共享属性的需要（使用 ABC - Product 的抽象基类），P1、P2、P3 的子类型（给它一个有意义的域名) 和多态性来改变价格计算。

您的订单将包含基本产品参考列表并获得总数，您将询问每个产品的价格并使用迭代器累积它们。

于 2010-08-04T13:43:07.510 回答
1

在我看来，这听起来像是何时使用策略模式的完美示例。如果您使用类继承来定义产品的定价方式，那么如果后来有人决定 WidgetXYZ 现在应该按重量定价，而不是简单的价格，那么您将不得不重新编译整个系统。

我会将每种产品定义为具有“PricingStrategy” - 在您的情况下，这将是“volumeDiscount”、“byWeight”或“simple”。然后，您可以使用工厂根据产品的策略提供正确的 PriceCalculator 对象，并且该 priceCalculator 将相应地计算产品的价格。

于 2010-08-04T18:48:09.127 回答