我正在设计一个库存系统。每个库存项目的税费都需要根据许多条件(州、县等)进行计算。计算规则也会随着时间的推移而变化。所以我在考虑策略模式,但我在制定设计说明方面没有丰富的经验。
我还应该问自己什么其他问题?
我的库存项目可以是不同的类型,所以关于策略模式的 wiki 页面说:
类的行为不应被继承,而应使用接口封装。
这对我的案件有何影响?
我正在设计一个库存系统。每个库存项目的税费都需要根据许多条件(州、县等)进行计算。计算规则也会随着时间的推移而变化。所以我在考虑策略模式,但我在制定设计说明方面没有丰富的经验。
我还应该问自己什么其他问题?
我的库存项目可以是不同的类型,所以关于策略模式的 wiki 页面说:
类的行为不应被继承,而应使用接口封装。
这对我的案件有何影响?
类的行为不应被继承,而应使用接口封装。
这意味着,您应该将计算算法封装在接口后面,然后在指向正确 Strategy 对象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);
}
}
因此,策略绝对是抽象您的税收计算的一个很好的解决方案。如果在某个时间应用的计算规则不同并且可以更改,我也会使用工厂来创建正确的 Strategy 对象。
我认为你需要加强你的设计,看看税收计算的过程是如何发生的,何时完成,由谁,为谁以及在哪里记录。对此负责的人会将库存项目作为输入,然后需要找出给定项目(和上下文)属性的适用税收计算方法。该过程可能涉及向税收计算政策对象询问合适的方法。非常高的水平应该是这样的:
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)
因此,策略模式可以在将上述过程与计算方法的细节 以及在给定库存项目的情况下寻找合适方法的细节中隔离开来发挥基本作用(因此它已经被使用了两次),但这只是一个实现细节的整体设计。许多其他模式可能适用,从工厂到存储库,或用于复杂标准的规范和组合,仅举几例。
要获得启发,请查看一些会计分析模式 (pdf)。