Hey Bill,
What you said makes a lot of sense... if I have a GetObject helper method within the CFC itself, then I will only have to worry about how the object is referenced in one place... actually maybe 2 places because if I originally passed in the object and then changed that to creating the object using factory, I would have to remove the variables.Object=arguments.Object mapping in init(). It seems that everytime I'm stumped, another abstraction is the way to go. Imagine - just yesterday I was actually creating objects using createobject()!! Could I have been anymore barbaric? ;-) Baz -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Rawlinson Sent: Monday, October 31, 2005 10:59 AM To: [email protected] Subject: Re: [CFCDev] Global Function Libraries I would suggest that you have a helper method in your user object that provides accessor control to the object it is dependant on (someOtherObject). This way, regardless of what the factory does (passes in the object, or a reference to the factory) on initialization of the User object the User object will be easier to maintain in the long run. Lets say for example that your user object needs a TrainingHistory object passed in during your early iterations of development. Then down in the bowels of the User object you are referencing the TrainingHistory object as variables.instance.trainingHistory.getClasses(1984) to get the courses that User took in 1984. This works fine for a while but then you do some more things and end up neededing references to three or four objects throughout your user object. So you decide to pass in the factory object instead of the TrainingHistory object (and the others). Now you will have to go back and update your code whereever you referenced variables.instance.trainingHistory to call variables.instance.factory.getTrainingHistory or something along those lines. However, if you just have a getTrainingHistory method in your User object that you call everytime to get the objects reference then it won't matter to the rest of your code (within the User object) how the User object gets a reference to the trainingHistory object - it will always call the getTrainingHistory method. Perhaps I am just being redundant by mentioning this but I figured I'd be on the safe side and say it anyway. Typically, if I have any properties to my object that can be used, whether they are privately used or publicly used, I always call the accessor method to fetch them (and the mutator to set them) so that the setting and fetching logic only has to be maintained in one place. Bill On 10/31/05, Nando <[EMAIL PROTECTED]> wrote: > I *think* i get what you're asking. > > I don't think it's essentially important. But here's my take on it. > > If the User object, to function properly, needs that object and you don't > need Factory in User to create object instances again and again, then i'd > just do it all in Factory and pass the created object in. Then it's more > transparent to you down the line. > > IF User needs multiple instances of an object or several objects in the > course of it's lifetime, then it needs Factory's help. Pass Factory into > User in the User.init(). > > It always takes me a little time to "get" a particular pattern. I have to > play with it awhile and really see the various ramifications behind it. Then > i feel like i "get" it ... and of course there may be deeper layers to my > understanding that are revealed down the line. > > So you're probably going to need to play with this way of doing something > for a few days or weeks until it settles for you. Once that happens, then > suddenly ColdSpring might look like an amazing piece of code to you and me. > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >Behalf Of Scratch > >Sent: Monday, October 31, 2005 3:40 PM > >To: [email protected] > >Subject: RE: [CFCDev] Global Function Libraries > > > > > > > >Nando my question was much simpler than that - AND I PROMISE IT'S > >THE LAST! > > > >I was only asking that if my UserCFC needs to have a second related object > >within it, should that second object be created in the User.cfc's init() > >(using the passed in factory ofcourse) OR should the factory just have > >created an instance beforehand (in the makeUser method) and passed it in as > >an argument? > > > >Both A. and B. are the contents of makeUser(): > > > >A. MAKEUSER() CREATES SECOND OBJECT BEFOREHAND AND PASSES IT IN > ><cfset SecondObject=load('SomeRelatedCFC')> > ><cfset ReturnObject=createobject('component', 'User').init(SecondObject)> > > > >B. MAKEUSER() JUST CREATES THE PRIMARY OBJECT AND LEAVES THE > >CREATION OF THE > >SECOND OBJECT TO THE INIT() > ><cfset ReturnObject=createobject('component', 'User').init()> > > > >In example B., the init() of User.cfc would have the > >load('SomeRelatedCFC') > > > >Thanks again, > >Baz > > > > > > > >-----Original Message----- > >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > >Of Nando > >Sent: Monday, October 31, 2005 9:22 AM > >To: [email protected] > >Subject: RE: [CFCDev] Global Function Libraries > > > >Not exactly sure what you're asking here, but i think the basic OO premise > >here is cohesion - give Factory one job to do, creating objects, and let it > >do it well. > > > >Some Factories have Warehouses attached to them to store stuff they create, > >but essentially a Warehouse is a different specialization. You don't want > >piles of widgets laying around all over the Factory floor. > > > >I'm not sure if it's a good idea to use our Factory as a Warehouse for some > >of the objects it creates for the application. The API becomes less clearly > >defined and focused. We're losing cohesion. > > > >In your particular app, i'm not sure we need a specialized "Warehouse" to > >store created objects - maybe we should call it a GlobalService > >object - but > >maybe we do! It all depends on the context. > > > >If we do ... then Factory can create it for us, pass itself and whatever > >other instantiated objects are needed in there, and then when certain > >objects need GlobalService and all it can provide, Factory gives them a > >reference to it when creating them. > > > >Now i gotta get some work done! > > > >ciao, > >nando > > > >>-----Original Message----- > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > >>Behalf Of Scratch > >>Sent: Monday, October 31, 2005 2:50 PM > >>To: [email protected] > >>Subject: RE: [CFCDev] Global Function Libraries > >> > >> > >> > >> > >>Should I then always create dependent objects in the Factory and then pass > >>them into the CFC? Or should I use the factory in the CFC to create the > >>object. Examples: > >> > >>EXAMPLE A (CREATE DEPENDENT OBJECT INSIDE CFC) > >> > >>**Factory.cfc** > >> > >><cffunction name="makeXXX" returntype="XXX"> > >> <cfset var XXXObj = createObject('component','XXX').init(this) /> > >> <cfreturn XXXObj /> > >></cffunction> > >> > >>**XXX.cfc** > >> > >><cffunction name="init" returntype="XXX"> > >> <cfargument name="Factory" /> > >> <cfset variables.instance=structnew() /> > >> <cfset variables.instance.Factory=arguments.Factory /> > >> <cfset variables.instance.LTO= > >>variables.instance.Factory.load('XXXLTO')> > >> <cfreturn this /> > >></cffunction> > >> > >>OR EXAMPLE B (CREATE DEPENDENT OBJECT FIRST IN FACTORY) > >> > >><cffunction name="makeXXX" returntype="XXX"> > >> <cfset var LTO = load('XXXLTO') /> > >> <cfset var XXXObj = createObject('component','XXX').init(this,LTO) /> > >> <cfreturn XXXObj /> > >></cffunction> > >> > >>**XXX.cfc** > >> > >><cffunction name="init" returntype="XXX"> > >> <cfargument name="Factory" /> > >> <cfargument name="LTO" /> > >> <cfset variables.instance=structnew() /> > >> <cfset variables.instance.Factory=arguments.Factory /> > >> <cfset variables.instance.LTO= arguments.LTO> > >> <cfreturn this /> > >></cffunction> > >> > >> > >>Cheers, > >> > >>Baz > >> > >> > >>-----Original Message----- > >>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf > >>Of Nando > >>Sent: Monday, October 31, 2005 8:08 AM > >>To: [email protected] > >>Subject: RE: [CFCDev] Global Function Libraries > >> > >>>Also, what if CFCs need to create objects, how do they call the > >Factory if > >>>its in the app scope? > >> > >>:) > >> > >>Isn't this stuff great to think about? > >> > >>In the previous example, let's say your ServiceObj needed Factory to > >>createObject()'s for it. > >> > >><cffunction name="makeServiceObj" access="private" returntype="ServiceObj" > >>output="no"> > >> <cfset var ServiceObj = > >>createObject('component','ServiceObj').init(variables.Utils, this) /> > >> <cfreturn ServiceObj /> > >></cffunction> > >> > >>That's all you'd need to do! Well, almost ... Did you notice the > >>difference? > >>:) > >> > >>Then in the init() of ServiceObj, all you'd need is this: > >> > >><cfset variables.Factory = arguments.Factory /> > >> > >>Of course, once you've got a reference to Factory in your ServiceObj, then > >>you wouldn't need necessarily to pass Utils into it. You could just ask > >>Factory for a instance: > >> > >>In Factory: > >> > >><cffunction name="makeServiceObj" access="private" returntype="ServiceObj" > >>output="no"> > >> <cfset var ServiceObj = > >>createObject('component','ServiceObj').init(this) > >>/> > >> <cfreturn ServiceObj /> > >></cffunction> > >> > >>Then in the init() of ServiceObj, all you'd need is this: > >> > >><cfset variables.Factory = arguments.Factory /> > >><cfset variables.Utils = variables.Factory.load('Utils') /> > >> > >>None of these examples are "perfect" ... it all really depends on the > >>context of your application and your skill and preferences as a developer. > >>The point is that we're headed down a different path, using some OO > >>principles to create a more robust, flexible app. What just happened was a > >>requirements change. You suddenly needed the capability to createObject() > >>within some ServiceObj. And you got it with no change to Factory's public > >>interface, load(), and a very minor change to makeServiceObj() and > >>ServiceObj.init() > >> > >>If you find yourself battling with "scopes" - you haven't come up with the > >>right architecture yet! > >> > >> > >> > >> > >> > >> > >>---------------------------------------------------------- > >>You are subscribed to cfcdev. To unsubscribe, send an email to > >>[email protected] with the words 'unsubscribe cfcdev' as the > >>subject of the > >>email. > >> > >>CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > >>(www.cfxhosting.com). > >> > >>An archive of the CFCDev list is available at > >>www.mail-archive.com/[email protected] > >> > >> > >> > >> > >> > >>---------------------------------------------------------- > >>You are subscribed to cfcdev. To unsubscribe, send an email to > >>[email protected] with the words 'unsubscribe cfcdev' as the > >>subject of the email. > >> > >>CFCDev is run by CFCZone (www.cfczone.org) and supported by > >>CFXHosting (www.cfxhosting.com). > >> > >>An archive of the CFCDev list is available at > >>www.mail-archive.com/[email protected] > >> > >> > > > > > > > > > > > >---------------------------------------------------------- > >You are subscribed to cfcdev. To unsubscribe, send an email to > >[email protected] with the words 'unsubscribe cfcdev' as the > >subject of the > >email. > > > >CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting > >(www.cfxhosting.com). > > > >An archive of the CFCDev list is available at > >www.mail-archive.com/[email protected] > > > > > > > > > > > >---------------------------------------------------------- > >You are subscribed to cfcdev. To unsubscribe, send an email to > >[email protected] with the words 'unsubscribe cfcdev' as the > >subject of the email. > > > >CFCDev is run by CFCZone (www.cfczone.org) and supported by > >CFXHosting (www.cfxhosting.com). > > > >An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). > > An archive of the CFCDev list is available at www.mail-archive.com/[email protected] > > > -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask. ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
