I would call this a "Strategy" pattern, because the class to instantiate varies and is determined at runtime, but the lines between Factory and Strategy can get blurry. Either way would work, but I would lean towards the separate class, because that centralizes the code and it can be called from more than one place. Then again, maybe you know that the tax table will never be instantiated by any class except the Country class. In that case, it comes down to personal preference and go with which feels best to you. Our factory/strategy is data-driven rather than using CASE statements.
>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.
