关于分类的建模问题。子类型还是不子类型？
我需要一些关于如何建模这个简单分类（？）示例的建议：
我有一个产品。产品可以有不同的类型，例如 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 语句。如果我选择对它们进行子类化，每个类都可以负责计算正确的价格，或者任何要求做的事情。
I need some advice on how to model this simple categorization (?) example:
I have a product. A product can be of different types, such as ProductType 1, ProductType 2, and ProductType 3. All products have a part number and a name. Where they differ, is the way their prices are calculated.
- Products in type 1's price are dependent on how many there are of the product. So if I have 5 products, the price is $x. If I have 20 products, the price is $y, and so on.
- Products in type 2’s price are dependent on each products weight. If the weight is 5 kg, the price is $x, and so on.
- Products in type 3’s have a simple price, like $x for each product.
The way I see it, each “price structure” needs to have a dedicated table/class. A product will then have a reference to its price structure, dependant on the type of the product. Would you just create a “product type” table and have an attribute called Type on the Product class, or would you use generalization, so Product 1/2/3 are a subtype of Product?
There will be like 5 different price structures, and the way the price is calculated differs from each type. So the logic calculating the total price for an order is dependent on each product type.
Can you give me some advice on how to model this the best way? If I choose the approach where there’s a Type attribute on the Product class, I imagine that I will get lots of if-else statements in my code. Where if I choose to subclass them, each class can be responsible for calculating the correct price, or whatever it is asked to do.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
在我看来，这听起来像是何时使用策略模式的完美示例。如果您使用类继承来定义产品的定价方式，如果后来有人决定 WidgetXYZ 现在应该按重量定价，而不是简单的价格，则必须重新编译整个系统。
我将每个产品定义为具有“PricingStrategy” - 在您的情况下，这将是“volumeDiscount”、“byWeight”或“simple”。然后，您可以使用 Factory 根据产品的策略提供正确的 PriceCalculator 对象，并且价格计算器将相应地计算产品的价格。
This sounds to me like a perfect example of when to use the Strategy pattern. If you use class inheritance to define how a product is priced, you'll have to re-compile your entire system if someone later decides WidgetXYZ should now be priced by weight, instead of having a simple price.
I would define each product as having a "PricingStrategy" - in your case this would be either "volumeDiscount", "byWeight", or "simple". You could then use a Factory to provide the correct PriceCalculator object depending on the product's strategy, and that priceCalculator would calculate the product's price accordingly.
我的建议是，在您的关系数据模型中，您将有类型列来区分记录类型。在代码中，您绝对应该使用子类化。域模型应该尽可能独立于底层数据模型，并且您的描述很好地支持共享属性的需要（使用 ABC - Product 的抽象基类）、P1、P2、P3 的子类型（给它一个有意义的域名） ）和多态性来改变价格计算。
您的订单将包含基本产品参考列表，为了获得总数，您将询问每个产品的价格并使用迭代器累加它们。
My suggestion is that in your relational data model, you will have the type column to distinguish the record type. In the code, you should definitely use sub-classing. The domain model should be independent of the underlying data model as much as possible and your description well support the need of sharing attributes (using ABC - abstract base class for Product), subtype to P1, P2, P3 (give it a meaningful domain name) and polymorphism to vary the price calculation.
Your order will hold a list of base product reference and to get the total, you will ask each product for the price and accumulate them using iterator.