>>>
>>>All of this is a matter of taste, of course - if you feel more comfortable in that direction, why not. If that makes you more productive and eases the maintenance, again why not. So this is just an opinion.
>>
>>Way I see it the UML is the blueprint, not a tool. When the architect provides the blueprints, it's not normal for the construction people to deviate. ;)
>
>For which you as an architect will rant against yourself as a builder and vice versa :).

I wish that were so. I can architect stuff but the builder in me wishes everything was easier. Maybe that's one of the reasons I'm looking at design patterns.

>
>>The GOF showed how to build what they described and I'm interested in being true to that design. That way the one UML can be applied to several languages.
>
>The car can be any color as long as it's black :).
>
>I somehow don't see the GOF patterns applicable to languages like VFP, Python, JavaScript and a few others where the on-the-fly building of objects and various methods of macro substitution and interpretation are available and regularly used...
>
>>I understand it may be a VFP specific extension. I did it as a data driven factory, which may be done and still fit the GOF UML for the factory, not the abstract factory.
>
>...as in VFP, for one, we don't need a distinction between an abstract and concrete factory. Those 200 lines of code do both. Actually, if we remove some error checking and user library, it can be done in about 60 lines.


OK. Let's do something really really useful.

I for one am completely fed up with having to build city, state and country screens all the time. Almost every project has these.

I want to build a country screen to maintain country code/abbreviation, name and postal code format.

I want to build this thing one time and reuse it for all my different projects.

That means I may want to have multiple classes, but instantiate a different one per customer - some customers will have needs the others do not. Postal code format will be the variable feature.

The data driven factory can have a different table per customer, so it can instantiate the "correct" one.

How should we design that?