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.

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.

I used the factory to create a container. I can change the entry in the table to specify which container. I can even change the table name in the factory class to have it create different classes. That's neat.

This container needs 2 buttons, search and clear. The init can call a pair of methods of the container that use the data driven factory to drop on the two buttons. That's neat. However, I think it's not as flexible as it could be.

The two buttons are similar concrete classes specific to this search container. So, I should have an abstract factory to return the search button OR the clear button (via their respective factories). Their factories are a good place to control the appearance of the buttons.

So the abstract factory would need a parameter tcButtonType. Based on that it would instantiate the right factory. That factory would instantiate the right button (still can data drive it) and then customize the button.

Common functionality would exist in the button classes, controlled only by properties set by the factory - since it is difficult to dynamically write and test code in the buttons.

I'd like dictionary perfect examples to increase my understanding of the design patterns. If I'm right in my current thinking this is a very flexible way to go and it's not that difficult to put together.

A better example would be a customer form. I think I could now completely customize the customer form from a single class into any number of different applications, without subclassing.

Does that seem right to you?

Thanks

>>To start, you would create an Abstract Factory that simply defines the interface for the Concrete Factories. I don't think that the Abstract Factory actually creates the Abstract Products (that wouldn't be very "abstract" would it? <g>), so the wording is confusing to me, but I could be missing the point. Anyway, I think the main function is to provide an interface for the concrete subclasses, and it would look something like this:
>>
>>AbstractControlFactory.CreateTextBox()
>>AbstractControlFactory.CreateCommandButton()
>>AbstractControlFactory.CreateCheckBox()
>>...
>
>My point in this thread was that, no matter how abstract the patterns try to be, and how unrelated to any specific language, they still are. The GOF are obviously thinking in C++, and the patterns they lay out are probably a great set of names for common tools while designing a system... in C++ or a similar language which can't create an object from an externally stored string. IOW, if you can't just
>
>

if !used("factory")
>   use factory in 0
>endif
>lcClass=alltrim(factory.ClassName)
>lcClassLib=alltrim(factory.ClassLib)
>*-- insert some error checking here
>oObj=newobject(lcClass, lcClassLib)
>*-- insert some error checking here
>return oObj

>
>...then you probably do need special factories for any family of classes. In VFP, you don't need that. You may achieve factories by simply adding more fields to factory.dbf, and use them to group your class tokens in any manner you like - familial, by classlib, by political or whichever orientation. Use your imagination if you want, but we don't need that.
>
>>You would then create subclasses of this factory for each platform you wish to target. For your standard VFP controls, you would have a VFPControlFactory, which actually contains the code to create a textbox, command button, checkbox, etc. from your VFP classes. You could create similar Concrete Factory subclasses for WebControlFactory or AvalonControlFactory, which would have their own sets of Concrete Product subclasses to instantiate. Your code would look something like:
>>

>>loControlFactory = CreateObject("VFPControlFactory")
>>loTextBox = loControlFactory.CreateTextBox()
>>loCommandButton = loControlFactory.CreateCommandButton()
>>loCheckBox = loControlFactory.CreateCheckBox()
>>...
>>

>
>OK, how would loControlFactory be different from loSessionFactory or loCursorAdapterFactory? And within VFPControlFactory, how would code in CreateTextBox() be different from code in CreateCheckBox()? Shouldn't both of them have NewObject(cClassname, cClasslib)? And what else should you need in one that you wouldn't need in the other?
>
>I've searched my drives for the GOF book, but it seems I deleted it, and the original CD is, well, somewhere (we moved twice since I bought it, so...), but from what I remember about the factory pattern, in C++ there's no way around hardcoding the list of the classes somewhere. In VFP, we have the NewObject() function and method, and they both accept string variables for parameters, and the code for the classes that would be created doesn't necessarily need to be inside the project. Two big things come out of this:
>
>1) we don't need to hardcode the names of our classes in the factory's code
>2) we don't really need to rebuild the exe each time we add or change a class.
>
>So, a VFP factory can be much simpler, and can be written in about a hundred lines (with all the checking, comments, alternate factory tables etc). And guess what, not a single class's name needs to be mentioned in it.
>
>I'm not saying that keeping your classes outside of the exe is a good programming practice, nor that I would recommend it - however, keeping them all inside is not really mandatory.
>
>>Of course, you would not hard-code the "VFPControlFactory". That would defeat the purpose. Also, it is not a requirement to create the factory each time you create an object. You could create the factory as a global object at startup if you wanted, but that's just an implementation decision.
>
>Or one per datasession - see the discussion upstream in this thread.
>
>>That's the Gang of Four pattern and implementation as I understand it. Of course, the first thing a Fox developer did was get rid of Concrete Factory classes and data-drive the whole thing. This works well in VFP, but to keep things in perspective, you could consider the DBF the "Concrete Factory". Swapping the DBF with one that points to a different set of classes has the same effect as using a different Concrete Factory.
>
>There you are :). I should have read this before I wrote all of the above...