I like the second one better, because it gives me a consistent interface to program to.
 
But it's true what you say that it's more confusing, because then you always have to check if an object needs args passed into it before calling Factory.load()
 
So what about another public interface for Factory? How about if we leave load() as it is so we're always clear about what it does and create a loadInit() method in Factory: (and yes, maybe there's a better name for it ... )
 

<!--- loadInit --->

<cffunction name="loadInit" access="public" returntype="any">

            <cfargument name="ObjectName" type="string" required="yes" />

            <cfargument name="initArgs" type="struct" required="YES" />

 

 

What do you think of that approach?

 

I'd definitely prefer that Factory handles the the init() for me in it's own black box, but i certainly have situations where i need to pass application state stuff into objects to instantiate them. It doesn't seem like it's within Factory's mandate to know "everything". And it certainly is unpredictable what some yet to be designed object may need in it's init() method, even if it always needs the same exact thing.

 

So how do you feel about providing 2 interfaces in Factory? load() and loadInit()?

 

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Nando
Sent: Wednesday, November 02, 2005 7:07 AM
To: [email protected]
Subject: RE: [CFCDev] Factory Pattern

:) - back so soon?
 
myInstance = application.Factory.load('myObj')
myInstance.init(InitParametersCouldGoHere)
 
 or what about this?
 
myInstance = application.Factory.load('myObj',args)
 

<!--- load --->

<cffunction name="load" access="public" returntype="any">

            <cfargument name="ObjectName" type="string" required="yes" />

            <cfargument name="args" type="struct" required="no" />

 

 

Which do you like better? If you prefer one over the other, why?

 

 

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Scratch
Sent: Wednesday, November 02, 2005 6:15 AM
To: [email protected]
Subject: [CFCDev] Factory Pattern

 

I was recommended to build a Factory object to create my CFCs in the following manner:

 

<!--- init --->

<cffunction name="init" access="public" returntype="SystemFactory">

            <cfreturn this />

</cffunction>

 

<!--- load --->

<cffunction name="load" access="public" returntype="any">

            <cfargument name="ObjectName" type="string" required="yes" />

 

            <cfset var ObjectInstance="" />

 

            <cfinvoke method="create#arguments.ObjectName#" returnVariable="ObjectInstance" />

                       

            <cfreturn ObjectInstance />

</cffunction>

 

<!--- createObjectXXX --->

<cffunction name="createObjectXXX" access="private" returntype=" ObjectXXX ">

                       

            <cfset var Object=createobject('Component','SystemCFC.ObjectXXX).init() />

                                               

            <cfreturn Object />

</cffunction>

 

The load() method takes a CFC name and calls the appropriate Create() method. My app should only call load().

 

First off is this a good way? Secondly, if I use this way I seem to lose the ability to pass already instantiated objects to my init() methods - ofcourse I can still create new dependent objects and pass them in, which is the point of the whole thing, but what about passing in already instantiated objects? How does that work with Factories?

 

Anyone care to post a link to their Factory file ;-)

 

Cheers,

 

Baz

----------------------------------------------------------
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]

Reply via email to