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]
