>>>>The factory that I use is data driven from a DBF. The DBF has filed for the Item name that I want to create and other fields that hold the classlib and classname that should be used. This way I can;
>>>>
>>>>

>>>>loFactory = Cretae("Factory")
>>>>loWait = loFactory.GetObject("MyPleaseWait")
>>>>* Now loWait is which ever class the factory data file says it should be
>>>>* I can change the form by changing the metadata and no code change is needed
>>>>* I cna mov3 the classlibs around as long as I update the metadata
>>>>

>>>
>>>That's one of the approaches I outlined. The questions I have revolve around the implementation matching the definition. In this case, your "client" is employing a data driven factory method patten, not an abstract factory pattern?
>>>
>>>Do you not lose a potential for decorating the MyPleaseWait by not using a MyPleaseWait factory as loFactory?
>>
>>And what would be gained by having multiple factories around, except unnecessary complexity? :)
>
>There is EPSON factory, BEER factory, BMW factory, MAZE factory:
>
>http://www.devshed.com/c/a/PHP/Design-Patterns-in-PHP-Factory-Method-and-Abstract-Factory/
>
>Each specializes! One factory cannot make everything.

Yours does. Jim's does.

>This makes documents
>http://www.dofactory.com/Patterns/PatternFactory.aspx
>
>This makes cars
>http://home.earthlink.net/~huston2/dp/factory.html
>
>Design Pattern 1:M Implementation
>
>>
>>What's the purpose of the factory? To reduce the complexity of creating an object (i.e. you don't need to know where is it defined and what's its exact name today), and to have the ability to try out different versions of classes around without having to rename them to whatever they may be mentioned as, in various places around the app. You only need to know the token name.
>
>That sounds good, but where is "token" in those examples?

The name of the class you want, which will be used to find the class and classlib in factory.dbf.

>>Now if you want to have multiple factories, you... need to know their names. And how would these factories be different from each other? What else should they do but just instantiate the object you want?
>
>That's what I'm trying to understand. The definition says "without specifying the concrete class". It doesn't say anything about specifying the factory.

It does in the examples you pointed out - but the unnecessary complexity there is there simply because the examples are not data driven. So while they reduce the complexity somewhat by introducing a factory (I've read both the C# and PHP examples, plus the article), they still have to hardcode the names of the classes to produce inside the concrete factory class itself. Not data driven.

With a simple VFP factory and a factory.dbf, you can just add a line with a name, class, and a something.fxp for classlib, add the .fxp to app's directory, and your app now uses the new class without even recompiling.

IOW, with a factory class as simple as this, we have both the abstract and concrete factory in place:

define class factory as custom
procedure create(cToken)
if seek(cToken, "factory","token")
   oObj=newobject(alltrim(factory.class), alltrim(factory.classlib)
else
   oObj=null
endif
return oobj
enddefine

(OK, need to add opening/closing the table, some error checking, variable declarations, additional parameters passed to the new object etc, but this is the meat of it)

For this, we don't need any concrete/abstract factory distinction. This one does all we need. It can make cars, doors, coffee and up (as in "makeup" :). Don't let yourself be confused with limitations of other languages, which then influence the books and articles.