Oop 面向对象设计

我的任务是编写一个简单的程序，为杂货店的顾客打印收据。知道基本销售税适用于除书籍、食品和免税医疗产品以外的所有商品，税率为10%进口税是适用于所有进口货物的附加销售税，税率为5%，无任何豁免

输入示例：1本书10美元，1块进口巧克力5美元，依此类推

我想使程序尽可能面向对象。所以我的层次结构是这样的：

顶层的层次结构是抽象类Item（name，price），然后我将拥有类SaleTaxItem（需要支付10%税的items）和非saletax Item类从Item扩展而来。问题是我是否应该在上面的每个类中创建一个名为isImported的布尔变量，这样我就知道什么时候该多收费5%了？还是应该为导入的项目创建一个新类

---

这个设计对于这个任务非常重要，所以我想让它变得完美。谢谢

关于何时使用继承和何时不使用继承，人们进行了大量的讨论。在这种情况下，我不会使用继承来为项目建模

为什么?？因为在现实生活中，这些税收和关税规则在时间、空间（如你所在的州）以及你经营的公司类型上都会频繁变化。如果每次地方和联邦政府更改其法规时都必须更改类层次结构，那么您就注定要失败—更新将更改您已有实例的类—您的项目

另一个注意事项：如果使用类（有效地）将销售“标记”为有税和/或关税，那么最终会出现一些没有标记接口的项目，以及一些具有多重属性的项目，即使用多重继承。你需要四节课。再加上一些额外的规则，您就有了一个类爆炸（要考虑的税收/关税的因数）

另一种实现是拥有一个属性，该属性是该项目所拥有的税收和关税的集合。所以你们有两门课：

• 项目
  • 清单：税收
• 税
  • 字符串：名称
  • 双倍：百分之

Tax有许多全局实例—SalesTax和ImportDuty。然后，一个项目在列表中有零个、一个或两个税务实例（该列表还表示应用税务的顺序）

最后一种方法对未来的税收变化（包括增加新税收）也有更好的证明

编辑一夜之间我有一个改进的建议：

图中有两个“翅膀”：

抽象项目层次结构，处理项目及其税费

TaxOrDuty层次结构和TaxAssessor中的算法

AbstractItem在一个项上使用，将该项包装在税务层中——每个层由TaxedItem建模。最外层是一个包裹在所有适用税中的物品，使用装饰图案，除了虚增的价格外，外观和行为与物品相同。AbstractItem有几个有用的方法：

• getPrice（）：返回项目的完整价格
• getAllTaxes（）：传入一个空列表，该方法在收集TaxOrDuty实例的装饰器上递归。这对于能够逐项列出装饰物品的税费很重要
• getUntaxedItem（）：在装饰中递归，直到找到返回的项。这使得从装饰物品中轻松检索原始物品成为可能

在税收方面，有一个类TaxOrDuty，它模拟了税收的抽象行为。在这个天真的实现中，每个税都有一个统一的税率，但是您可以很容易地将该行为下推到一个FlatRateTax类中。其方法是：

• getRate（）：返回税率或关税的抽象方法。这是在子类上实现的
• computeTax（）方法获取一个项目，并根据getRate（）计算该项目的税费
• isApplicable（）是一个抽象方法，如果税项适用于该项，则返回true。这在SalesTax（始终返回true）和ImportDuty（返回项.isImported）上实现

税务评估员是负责协调适用税收分配的一类人员。它包含所有TaxOrDuty实例的列表（在本例中，仅包含SalesTax的一个实例和ImportDuty的一个实例）。它的方法applyTaxes（Item）调用isapplicatable（）迭代此集合。对于任何返回true的TaxOrDuty，TaxAssessor将该项包装在新的TaxOrDuty实例中（该实例当然引用TaxOrDuty）：

因此，您的总体答案如下：

Item item = new Item("Book", 10.0, false); // New $10 book, not imported
AbstractItem withTaxes = taxAssessor.applyTaxes(item);
double taxedPrice = withTaxes.getPrice();
List<TaxOrDuty> applicableTaxes = withTaxes.getAllTaxes(new List<TaxOrDuty>());

Item Item=新项目（“Book”，10.0，false）；//10美元新书，非进口
AbstractItem with Taxes=税务评估师。应用轴（item）；
double taxedPrice=withTaxes.getPrice（）；
List applicatabletaxes=withTaxes.getAllTaxes（新列表（））；

这种模式的主要优点是：

• 新税是可插入的
• 税务评估和计算算法是税务的一部分，而不是项目，因此非常复杂的税务可以在其自己的类中独立和正确地建模
• 责任（对我来说）是显而易见的，而且界限明确

---

为什么不编写一个方法

getTax（）

，该方法对SaleTaxItem返回10%，对可免除进口税的物品返回10%+5%（可能会覆盖？）？我认为布尔值不是一个好的可扩展选择：想象有一天我们引入了一种新的税收：我们需要引入新的布尔值吗？我们需要用int编码吗？是的，我有一个getTax（），我现在用一个布尔值来决定是否征收5%的进口税。我在Item类中实现了is_import boolean。如果我不使用布尔值，那么我应该使用什么？是否存在可能的重复项？我是否可以确定哪个项目是应纳税的？我的意思是，例如，我只有一个类项，当我创建一个新项并将名称“chocolate”提供给构造函数时，构造函数

Item item = new Item("Book", 10.0, false); // New $10 book, not imported
AbstractItem withTaxes = taxAssessor.applyTaxes(item);
double taxedPrice = withTaxes.getPrice();
List<TaxOrDuty> applicableTaxes = withTaxes.getAllTaxes(new List<TaxOrDuty>());