>Hey Jim
>
>>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? :)

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.

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?