>>>Hey Dragan et al
>>>
>>>An abstract factory is a factory that returns one of a set of common concrete factories to produce one of a set of common concrete classes.
>>>
>>>http://en.wikipedia.org/wiki/Abstract_factory_pattern
>>>
>>>To the best of my understanding a data driven factory is still just a factory. It is not an abstract factory.
>>
>>Somewhere upstream of this thread (and in the parts you quoted here) we had explained why we don't need the distinction between an abstract and concrete factory in a VFP data driven factory.
>>
>>>http://en.wikipedia.org/wiki/Factory_method_pattern
>>>
>>>What's the benefit of an abstract factory? AFAIK, it lets me order a car from a dealer. The dealer provides the car based on my requirements. They then decide which make and/or model to send me.
>>>
>>>If I want to order ice cream, I need a different abstract factory.
>>>
>>>I built a data driven factory, but what it does not give me is the ability to customize the end product.
>>
>>Why should it? The factory is a factory is a factory, it gives you a product you ordered.
>
>To make the interpretation of the UML clearer.

Not a good enough reason for me. UML is just a tool, and I'm not in the habit of redesigning my nails to fit a particular hammer. On the contrary, I think introducing levels of factories, parameters to factories etc only muddies the waters.

Besides, why would UML be concerned with the particulars of how an object is instantiated? Unless you're getting too detailed in your UML documents, or the concern of your design at this phase is the instantiation or some other technical matter, not the app itself.

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.