Why the load method? Well, it gives you a single interface to create an object for the rest of your app. Factory deals with it however it needs to. For instance, if down the line, Factory decides to delegate the work out to DAOFactory and GatewayFactory and BOFactory because they can do it cheaper, and just take a cut on the profits and kick back, the rest of your app doesn't need to know about it.
The reason for a unique method for each is because each object has potentially unique instantiation requirements. At least that's my reason. BUT ... consider it all carefully and come up with a better design! With a load method as your single interface, you can redesign how your Factory works and none of your calling code needs to change. One thing to realize tho' is that rather than scattering perhaps many createObject() calls for a certain object throughout your code, by putting it in a factory method like this, you can reduce the number of createObject() code blocks to one and only one per CFC in your app. Then, you only need to figure out what that object needs to instantiate it once, and if that need changes, or if you relocate the cfc to a different subdirectory / package, or if the mapping changes, there's only one place in your codebase where you need to modify those details ... in your Factory. So, yeah, there's potentially a number of methods in there, but if you've got 100 methods in your factory, think how many times you're NOT calling createObject().init(whatParametersGoInHereAgain?, WhichOrderDoTheyGoIn?, HowDoIMakeThemAvailableHere?, WhereIsThatUrlToSpike'sCFCExplorer?) in your code ... :) nando >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] >Behalf Of Scratch >Sent: Monday, October 31, 2005 3:39 AM >To: [email protected] >Subject: RE: [CFCDev] Global Function Libraries > > > >So there it is - my crash course in factories I just spent the last 2 hours >unsuccessfully googling about! Thanks Nando. > >I'm also in the process of checking out coldspring - seems clever so far. > >So since the Factory is responsible for creating objects it has to have >atleast one method per object - right? Your factory must be hundreds of >methods long... > >And why the generic Load() method? Why not call the make methods directly >from your app? > >i.e. ><cfset Customer=Factory.makecustomer()> > >Instead of: ><cfset Customer=Factory.load('Customer')? > >Cheers, >Baz > > >-----Original Message----- >From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf >Of Nando >Sent: Sunday, October 30, 2005 9:02 PM >To: [email protected] >Subject: RE: [CFCDev] Global Function Libraries > > >>Basic Questions >> >> - What's better, application scope or request scope? >> - Is it not horribly bad to refer to outside scopes form CFCs? >> > >I've said this before just a few days ago, but to me, the thing >that's "bad" >about it is that you're setting yourself up - to _not_ really learn OO >principles. To me that's "horribly bad" - or at least "kinda bad" ;) > >I'd forget about scope in this context (how to get things to work together >using scope) and start to train yourself to think about the architecture of >your app. Your CFC's need to play in harmony together and with the rest of >your app - you're the composer and conductor - how are you going >to do that? > >One of the keys i'm running across these days is using a Factory to create >your objects. Lemme map out a partial possible solution ... > >Instantiate a Factory as a singleton in application scope from your >Application.cfm or Application.cfc. This is the only cfc that's >instantiated >outside your Factory - all the rest are instantiated inside your Factory. > >In your Factory.init() method, have your Factory instantiate your function >library and place it in it's own variables scope. > >Any CFC that needs it gets a reference to the function library passed in >when your Factory creates it. > > ><cfcomponent displayname="Factory"> > > <cffunction name="init" access="public" returntype="Factory" >output="no"> > <cfargument name="dsn" required="Yes" type="string" /> > <cfset variables.dsn = arguments.dsn /> > <cfset variables.Utils = load('Utils') /> > <cfreturn this /> > </cffunction> > > <cffunction name="load" access="public" returntype="any" >output="false"> > <cfargument name="objectName" required="Yes" type="string" >/> > <cfset var myInstance = "" /> > > <cfinvoke > method = "make#arguments.objectName#" > returnVariable = "myInstance" > > <cfreturn myInstance /> > </cffunction> > > <cffunction name="makeUtils" access="private" returntype="Utils" >output="no"> > <cfset var Utils = createObject('component','Utils').init() >/> > <cfreturn Utils /> > </cffunction> > > <cffunction name="makeSomeObj" access="private" returntype="SomeObj" >output="no"> > <cfset var SomeObj = >createObject('component','SomeObj').init(variables.Utils) /> > <cfreturn SomeObj /> > </cffunction> > >.... > >OR another variation ... > > <cffunction name="makeSomeObj" access="private" returntype="SomeObj" >output="no"> > <cfset var Utils = load('Utils') /> > <cfset var SomeObj = >createObject('component','SomeObj').init(Utils) /> > <cfreturn SomeObj /> > </cffunction> > >.... > >What about when your custom tag needs a UDF? Do you think it would be >appropriate to return the instance directly from the Factory? > > <cffunction name="getUtils" access="public" returntype="Utils" >output="no"> > <cfreturn variables.Utils /> > </cffunction> > >Or would it be better to have it available from a singleton Service object >that's available to the rest of the app? > >In Factory > > <cffunction name="makeServiceObj" access="private" >returntype="ServiceObj" >output="no"> > <cfset var ServiceObj = >createObject('component','ServiceObj').init(variables.Utils) /> > <cfreturn ServiceObj /> > </cffunction> > >Out in the rest of the app: > >application.ServiceObj.getUils().someFunc() > >I'm not sure. It probably depends some on if you need a ServiceObj that >needs Utils anyway, and your preferences. The point here is that >the Factory >gave us a clean and easy way to create and compose objects, all in >one place >in our application. The question about whether to use request or >application >scope disappeared when we replaced it with a better question ... how can i >create and compose my CFC's easily? > >:) nando > > > > > >---------------------------------------------------------- >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]
