>>>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.
>>
>>From the info you give it looks like a matter of preference. That said, and without being able to clearly analyse my reasons, the first approach seems cleaner (and possibly more extensible).....
>>(My 10c)
>
>Don't you mean your 10p? ;-)

That would mean I would be charging significantly more for my opinions compared to those proffered on your side of the pond. I don't think the market will stand it - I'm reducing my charges to 6.25p

>Both approaches are so FoxPro IMO. I certainly have not mastered newer design technologies but one striking thing is there is little code so direct. I entered the business when everything was procedural and it's a very, very hard habit to break. It's like a right hander learning to eat left handed.

I don't think the *approach* is VFP - just, by virtue of the VFP language, the implementation,