Question

我正在设计一个库存系统。每个库存项目的税收需要根据许多条件（州，县等）计算。计算规则也会随着时间的推移而改变。所以我在想战略模式，但我在设计设计方面没有丰富的经验。

我应该对自己有什么其他问题？

我的库存物品可以是不同的类型，因此策略模式的维基页面上写着：

类的行为不应该是固有的，而应该使用接口封装它们。

这对我的情况有何影响？

Answer 1

一个阶级的行为不应该是固有的，而应该是使用接口封装。

这意味着您不应为每个可能的税收计算子类化Inventory项，而应将计算算法封装在接口后面，然后在Inventory类中使用封装，指向正确的战略对象。

这为您节省了大量工作，因为每次进行新计算时都不必声明新的Inventory子类。

以下实现使用继承：

abstract class InventoryBase
{
   protected abstract Money CalculateTax();
}

class InventoryTaxA : InventoryBase
{
   protected override Money CalculateTax()
   {
      // Calculation A
   }
}

class InventoryTaxB : InventoryBase
{
   protected override Money CalculateTax()
   {
      // Calculation B
   }
}

但策略模式如下：

class Inventory
{
   public Inventory(ITaxCalculationStrategy taxCalculationStrategy)
   {
      TaxCalculationStrategy = taxCalculationStrategy;
   }

   protected override Money CalculateTax()
   {
       return TaxCalculationStrategy.Calculate(this);
   }
}

因此，策略绝对是抽象税收计算的一个很好的解决方案。如果在某个时间适用的计算规则不同并且可以更改，我也会使用Factory来创建正确的策略对象。

Answer 2

我认为您需要对设计进行一些调整，然后了解税务计算的流程是如何发生的，何时完成，由谁，为谁以及在何处记录。对此负责的人将把库存项目作为输入，然后需要在给定项目（和上下文）属性的情况下找出适用的税收计算方法。该过程可能涉及向税收计算政策对象寻求合适的方法。非常高的水平会是这样的：

tax_calculation_method = tax_policy.get_method_for(inventory_item)
tax_value = tax_calculation_method.calculate_for(inventory_item)
tax_account.record_tax(tax_value, for_item: inventory_item)

因此，策略模式可以在将上述过程与计算方法 和的细节区分开来，从找到合适的的具体细节中发挥作用。方法给出库存项（因此它已经被使用了两次），但它只是整体设计的实现细节。许多其他模式可能适用，从工厂到存储库，或specifications和复合条件的复合材料，仅举几例。

要获得灵感，请查看一些accounting analysis patterns (pdf)。

哪种设计模式 - 基于许多输入参数的计算？

2 个答案: