Hi Mike,
I have no wish to fight -- and I don't think you can always use an abstract solution that doesn't take the language into account. It matters how the language works.
The factory doesn't seem lightweight to me. Is it data driven? If so, you need to open a table, or perhaps get a connection and query a datasource. If it's a case statement, you still have to know what factory class to use since each application needs its own class. If the factory is a singleton, now you have the DataSessionID issue. (Which you don't think is an issue, I know.) In my work there are times when there are lots of private DataSessions yet I have never used a SET DATASESSION TO once. When you instantiate the object in the dataSession you need it in, you don't do anything with dataSessions -- you just send a message to the object you wish to communication with. It has access to it's stuff.
The reason to have a UDF at all is to handle all the details of creating an object in one place and in the current dataSession. NewObjectX has to know that you might pass parameters. You might not have ThisApp available in which case you can just use the default class and classlibrary. I used to have this repeated and would call ThisApp.OF() in code each time I created an object. Obviously, repeating the code was bad, hence the NewObjectX(). However, if your goal, as you say, is to try to follow the book as closely as possible, never mind. I would think that someone who was able to realize that packages of one class per classlib are good (thanks very much -- you've convinced me) would seek out the practical over the theoretical.
>>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