I'm in the process of converting my entire app to make use of the Factory pattern thanks to you - I'm sure this will speed my settling in process.
Cheers, Baz -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando Sent: Monday, October 31, 2005 10:37 AM To: [email protected] Subject: RE: [CFCDev] Global Function Libraries 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] ---------------------------------------------------------- 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]
