>Hi Mike,
>I think your design is backwards.

Where I come from "Them's fightin' words." :)

How's that tuna commercial go? "Sorry Charlie."

>You have a method call that calls a UDF. One of my co-workers, Chris Bohling, created it as a UDF that calls a method. We use this sort of arrangement.

Frankly there's nothing wrong with an object calling a UDF. Chris' UDF calls upon an object to get the class and classlib and newobject it. Why have the UDF at all?

To me the whole point of Design Patterns was to turn commonly performed tasks into a set of "abstracts". Personally, I think they should have aimed for "standards". According to the oft published UML from the GoF book it seems an OBJECT is supposed to be creating another object. There was no mention of a UDF or procedure or data-driven or anything. I am trying to implement a design as close to the GoF book as possible. As long as the object encapsulates the design decisions, including whether to call on native commands/functions or even UDFs, that's good design.

There are lots of things that will work, but unless it matches the GoF book, they're all IMO "backwards".

VFP has datasessions, so IMO that means we deviate from the standard approach enough to deal with that idiosyncracy, not re-engineer the pattern.

Thanks


>

>ObjectCreatedInTheCurrectDS = NewObjectX(ClassName, ClassLibrary)
>
>FUNCTION NewObjectX(ClassName, ClassLibrary)
>IF VARTYPE(ThisApp) = 'O'
>   * The application object has the job of resolving
>   * the exact class and classlibrary to use.
>   ThisApp.OF(@m.Class,@m.ClassLibrary)
>ENDIF
>RETURN NewObject(m.ClassName, m.ClassLibrary)
>

>The actually UDF carries more code to deal with parameters you might wish to pass the init, and default ClassLibraries and such, but this is the idea. I always shudder when someone says,"Let's pass the dataSessionID." I know there are those who do it all the time, but to me it seems wrong. Is it so hard to create objects in the dataSession to which they belong?
>
>
>>Hey all
>>
>>Assuming we have a need to instantiate an object.
>>
>>SET CLASSLIB TO xxfwutil.vcx
>>loSafety = CreateObject("cusPushPopOnOff","SAFETY")
>>
>>This code is too tightly coupled to the class. If I subclass that class or rearrange the vcxs, I'm in for major reworking.
>>
>>A factory object is a solution.
>>
>>loSafety = CreateObject(oFactory.GetClassName("SetResetOnOff"),"SAFETY")
>>
>>First problem: oFactory must have been instantiated someplace, probably with a segment like:
>>
>>PUBLIC oFactory
>>set classlib to blah.vcx
>>oFactory = Createobject("myfactory")
>>
>>It seems preferable to have a single table for the factory.
>>
>>I suppose I have a few choices:
>>1 - If the application has a table, the factory class could be specified there.
>>
>>2 - I could have a UDF that instantiated the factory by looking in the same table. That seems like redundant code.
>>
>>3 - How about the factory object calls that same UDF?
>>
>>PUBLIC oFactory
>>oFactory = CreateObject(UDFGetClassName("Factory"))
>>.
>>.
>>.
>>loSafety = oFactory.GetClassName("SetResetOnOff"),"SAFETY")
>>
>>and inside GetClassName...
>>
>>lparameters tcClassName
>>lcClassName = UDFGetClassName(m.tcClassName)
>>
>>Any body see anything wrong with that?
>>
>>Thanks