IMO, a strategy is better. Have the calculation class determine if it should handle the calculation. If not, it knows the next class in the chain and calls it, passing the same parameters it received. Once one class handles things, it starts returning down the chain.

>I'm struggling with a decision that I have to make:
>
>For every year I have a different taxtable, and that per country.
>
>For instance:
>Taxtable_Aru2010
>Taxtable_Cur2010
>Taxtable_Aru2011
>Taxtable_Cur2011
>
>I have a class for the countries, and a class for the different taxtables.
>
>Should I create a factory class which takes as parameter the country and year, and returns the correct object?
>

>LPARAMETERS toCountry, tcYear
>*
>LOCAL loTaxTable AS Taxtable OF Taxtables.vcx
>*
>DO CASE
>    CASE toCountry.Name = "Aruba"
>        loTaxTable = NEWOBJECT("Taxtable_Aru" + tcYear","Taxtables.vcx")
>    CASE toCountry.Name = "Curacao"
>        loTaxTable = NEWOBJECT("Taxtable_Cur" + tcYear","Taxtables.vcx")
>ENDCASE
>*
>RETURN loTaxTable
>

>
>Or should I have a factory method in the Country class that returns the correct object for the taxtable?
>

>LOCAL loTaxTable AS Taxtable OF Taxtables.vcx
>*-- Call the factory method in Country.
>loTaxTable = loCountry.GetTaxtable(tcYear)
>

>
>What is wisdom here, is there a "right" way of doing this, or is this just a preference what I like more?
>One thing I can imaging is that the latter solution violates the single responsibility principle, because the country class should not be made responsible for deciding which taxtable to use. But on the other hand, it is in the context of the country that the decision is done...
>
>I would like to collect a few cents worth of ideas to buy a factory pattern.