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

L stands for "language", i.e. a communication tool. If under UML you mean the document written in that language, then yes, I'd agree it's a blueprint.

> 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 :).

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