面向对象设计问题
我有两种类型的产品 - 折扣（10% 光盘）和非折扣（0%） 其中每种产品都可以是本地产品/可出口产品，其中出口产品需缴纳 15% 的销售税。
模拟这种情况的最佳方法是什么？ 我是软件设计的绝对新手，我的想法非常有限 1. 有 4 种不同的产品子类型 2.使用Strategy模式，有4种不同的策略。
有人可以建议我如何使用上述选项或其他选项有效地对此进行建模吗？
I have a two types of products - Discounted (10% Disc) and NonDiscounted (0%) Each of these can be either LocalProduct / ExportableProduct with export one attracting a 15% sales tax.
What is the best way to model this scenario.
Me being absolute newbie to S/W design, I have very limited ideas
1. To have 4 different Product sub types
2. Use Strategy pattern and have 4 different strategies.
Can some one please suggest how can I model this effectively using the above options or other ones.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
为了简单起见，问问自己折扣是否真的需要成为子类型，或者它是否可以是产品的属性，其中“NonDiscounted”的折扣为零。
To keeps things simple, ask yourself if discount really need to be a subtype, or if it could be a property of the product, where "NonDiscounted" have a discount of zero percent.
我会这样做：
有一个名为“Product”的类，它具有产品的基本属性，如名称、描述、类型等。
基本“Product”类可以有一个名为“DiscountRate”的属性。对于非折扣，它可以是 0；对于折扣，它可以是任何值。这将有助于简化计算，因为始终应用相同的公式，只是在一种情况下折扣为 0。
然后您可以有两个类“ExportableProduct”和“LocalProduct”，它们都继承自“Product”类。
I would do this:
Have an class called "Product" that has the basic properties of a product like name, description, type, etc.
The base "Product" class can have a property called "DiscountRate". It can be 0 for non discounted and whatever value for discounted. This will help simplify calculation since the same formula will always be applied, just in one case the discount is 0.
Then you can have two classes "ExportableProduct" and "LocalProduct", they both inherit from the "Product" class.
类区分行为集。因此，让我们用这些术语来看看您的部门：
虽然可以认为折扣/非折扣是行为的一种变体，但将其简化为单一行为是微不足道的：所有产品都有折扣，但是非折扣产品的折扣金额恰好为 0%。这只是您产品的一个属性 (discount_amount)，而不是一个单独的类。
本地/可导出可能有也可能没有不同的行为。如果唯一的区别是产品是否允许国际运输，那么一个简单的布尔标志应该足以处理这种区别。另一方面，如果可出口产品需要本地产品不支持的行为（例如，记录海关要求和程序），那么将 ExportableProduct 设为 LocalProduct 的子类是适当的（如果可出口产品行为是本地产品行为的超集）。产品行为）或使用 LocalProduct 和 ExportableProduct 子类创建一个抽象 Product 类（如果本地产品也具有可导出产品不支持的行为）。
Classes distinguish sets of behavior. So let's take a look at your divisions in those terms:
While an argument could be made that discounted/non-discounted is a variation in behavior, it's trivial to reduce this to a single behavior: All products have a discount, but the amount of the discount happens to be 0% on non-discounted products. This is just an attribute of your products (discount_amount), not a separate class.
Local/exportable may or may not have distinct behaviors. If the only difference is whether the product is allowed to be shipped internationally or not, then a simple boolean flag should handle this distinction more than adequately. If, on the other hand, exportable products require behaviors not supported by local products (e.g., recording of customs requirements and procedures), then it would be appropriate to either make ExportableProduct a subclass of LocalProduct (if exportable product behaviors are a superset of local product behaviors) or make an abstract Product class with LocalProduct and ExportableProduct subclasses (if local products also have behaviors which are not supported by exportable products).
我建议也许折扣/非折扣根本不应该是产品类型。相反，父产品中有两个子类型和一个“折扣”属性/字段。每个产品都可以有效地享受任何折扣。这也允许不固定为 10% 的折扣。
I would suggest that perhaps Discounted/NonDiscounted should not be types of products at all. Instead have two subtypes, and a 'discount' property/field in the parent Product. Each product can then effectively have any discount. This also allows for discount that aren't fixed at 10%.
为此我会避免继承（即子类型）。
相反，我会为 Discounted / NonDiscounted 和 Local / ExportableProduct 定义枚举。每个产品类别都会有一个属性来指示其类型。
然后在一个单独的类中，例如：PricingCalculator，定义一个接受产品实例的计算方法（可能是静态的）。此方法仅检查枚举属性并在计算中应用所需的百分比值。
这将定价计算与产品本身完全分开，并允许您将有时复杂的定价计算保留在一个位置。随着您的定价方案随着时间的推移而变化，这种方法很容易维护和测试。
I'd avoid inheritance (ie sub typing) just for this.
Instead I'd define enumerations for Discounted / NonDiscounted and Local / ExportableProduct. Each product class would then simply have a property for each of these indicating its type.
Then in a separate class, eg: PricingCalculator, define a Calculate method (possibly static) that accepts an instance of a product. This method simply examines the enumeration properties and applies the required percentage values in the calculation.
This completely separates the calculation of pricing from the products themselves and allows you to keep sometimes complex pricing calculations in one location. As your pricing schemes change over time, this approach is easily maintainable and testable.
我会避免一切，只具有两个属性：
discount和local由于只有一件事会改变（价格），因此您可以即时计算它（discount => ;
价格 * .9，出口 => 价格 * .85 - 甚至两者 => 价格 * .9 * .85)I would avoid everything and just have two properties:
discountandlocalSince there is only one thing that changes (price), you can calculate it on the fly (discount =>
price * .9, export =>price * .85- or even both => export & discount =>price * .9 * .85)当更多事物根据类型而变化时，继承特别有用。
例如，如果折扣、税收和运输方式都根据商品类型而变化，那么绝对是时候考虑继承和子类化了（您会说“商品的这种子类型有这种税收和折扣，并且这次运输”）。
另一方面，当只有一个事物根据类型而变化时，那么是否值得拥有多种类型（即具有子类的基类型），或者是否可以将该差异更简单地建模为单个类型（其实例），就不太明显了具有属性值（例如，名为“discount_percentage”）。
Inheritance is especially useful when more than thing varies according to the type.
For example if the discount, and the tax, and the shipping method all varied depending on the type of item, then it's definitely time to consider inheritance and subclassing (where you'd say "this subtype of item has this tax and this discount and this shipping").
On the other hand when only one thing varies according to the type, then it's less obvious whether it's worth having several types (i.e. a base type with subclasses), or instead whether that variance can be modeled more simply as a single type, whose instances have a property value (e.g. named "discount_percentage").
当这就是您需要的所有行为时，只需在您的产品中包含两个布尔值并打开它们就是最好的解决方案。亚格尼。
但恐怕这只是一个更大问题的一小部分。然后你必须问自己：什么使产品成为产品（单一责任）。可征税性和可折扣性可能是两个不同的问题，因此您的产品最终有两种策略。
When this is all the behaviour you are going to need, just having two booleans in your product and switching on them is the best solution. YAGNI.
But I'm afraid it's just a small part of a larger problem. And then you have to ask yourself: what makes a product a product (single responsibility). Taxability and discountability are probably two different concerns, so your product ends up with two strategies.