What is the design pattern - calculations based on many inputs?

I am designing an inventory system. Each tax on inventory items must be calculated based on many conditions (state, county, etc., etc.). Settlement rules also change over time. So I thought about a strategy template, but I don't have much experience in creating design solutions.

What other questions should I consider as myself?

My inventory item may be of a different type, so the wiki page on the strategy template says:

The behavior of the class should not be violated, instead they should be encapsulated using interfaces.

How does this affect my case?

+3


source to share


2 answers


Class behavior should not be violated, instead they should be encapsulated using interfaces.

This means that instead of subclassing your element Inventory

for every possible tax calculation, you should encapsulate the calculation algorithm per interface and then use encapsulation within your class Inventory

that points to the correct strategy object.

This saves you a lot of work as you don't have to declare a new subclass Inventory

every time you have a new calculation.

The following implementation uses inheritance:



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
   }
}

      

But the strategy template will look like this:

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

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

      

So, a strategy is definitely a good solution for abstracting your tax calculations. If the rules to which the calculation is applied at a specific time are different and subject to change, I would also use Factory to create the correct strategy object.

+4


source


I think you need to take your design up a bit and see how the tax calculation process works, when it's done, by whom, for whom, and where it's written. Whoever is responsible for this takes an inventory item as input and then has to figure out that the applicable tax calculation method gave the item attribute (and context). This process may require you to query the tax calculation policy object for the appropriate method. A very high level would be like this:

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)

      



Thus, the strategy pattern can play a fundamental role in isolating the process described above from the specifics of the calculation method and in the specifics of finding a suitable method, taking into account the position of the inventory (so that it is already used twice), but this is just an implementation detail of the overall design. Many other patterns can be applied from factories to repositories or BOMs and composites to complex criteria, to name a few.

For inspiration, take a look at some accounting analysis templates (pdf) .

+3


source







All Articles