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