Jason,
Have to admit your post confused me a little...
My code was simply the most basic example that came to mind, in actual fact
I would have a singleton config.cfc that stores all the system config such
as dsn.
"I would prefer not to have to remember to write
this line when instantiating a Gateway object"
"In the calling page you only need...
objGW.getEmployees();"
sorry, so where did objGW come from?
I dont see how the calling page can reference an object that doesnt exist?
"The approach I thought about does not require the caller to pass in a
datasource argument"
Mine too?
"this approach breaks encapsulation because the component method relies on
another component called "systemGW"
i dont see how a component needing another component to work breaks
encapsulation, as long as the component that is relied upon is passed into
the component which is reliant.
config.cfc (singleton, created on app start)
gatewayfactory.cfc (singleton, created on app start, inited with config.cfc)
gateway factory creates each gateway, and in turn, inits them with the
config.cfc reference
every cfc is encapsulated?
"objSystemGW = CreateObject("component",".systemGW");"
I certainly would not do this, why create the object every time when the
singleton gateway can init your object with a reference to the singleton
system config?
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Jason Davey
Sent: 09 September 2005 15:45
To: [email protected]
Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use
the THIS scope for a ColdFusion Component?
Kerry:
I credit this approach by abstracting the dsn setting to a gateway cfc. My
goal is to make the interface as simple and as possible for the caller to
retrieve records following the idea that other programmers will want to
interface your components. I would prefer not to have to remember to write
this line when instantiating a Gateway object: "objGW =
application.gatewayfactory.load("someObjGW");" unless you do what I propose
below which is to embed this call within a GW component (then you don't have
to remember it!).
The approach I thought about does not require the caller to pass in a
datasource argument - instead the datasource becomes a private property of
the gateway component. However, this approach breaks encapsulation because
the component method relies on another component called "systemGW" and
method "getDataSource(), BUT, on balance (and that phrase is key in deciding
the solution), because we are dealing with APPLICATION scope variables, they
are more constant and therefore we can arguably get away with breaking the
pattern.
So...
In the init method you have:
<cfscript>
setDataSource();
return THIS;
</cfscript>
Modify the original setDataSource() method to call a systemGW object that in
turn gets the datasource value from an INI, registry or database setting ...
Use this method for all setting of datasources.
<cffunction name="setDataSource" access="private" returntype="void"
output="false">
<cfscript>
objSystemGW = CreateObject("component",".systemGW");
VARIABLES.datasource = objSystemGW.getDataSource();
</cfscript>
</cffunction>
In the calling page you only need...
objGW.getEmployees();
Thus making the interface very simple.
Jason D.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Nando
Sent: Friday, September 09, 2005 4:30 AM
To: [email protected]
Subject: RE: [CFCDev] Method parameters vs method names WAS: When to use the
THIS scope for a ColdFusion Component?
Kerry,
Hmmm, an all purpose factory. Do you handle it in some way if the CFC
doesn't exist? What about type checking?
I'm wondering if it would be better to call a getter with the load function
and if the getter doesn't exist, return an error. I like the single load
function tho'.
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Kerry
> Sent: Friday, September 09, 2005 10:08 AM
> To: [email protected]
> Subject: RE: [CFCDev] Method parameters vs method names WAS: When to
> use the THIS scope for a ColdFusion Component?
>
>
> My Answer:
>
> gatewayFactory.cfc
>
> function init(dsn,someargs){
> variables.instance.dsn = arguments.dsn;
> variables.instance.something = arguments.somethingelse; }
>
> function load(gatewayname){
> return
> createobject("component",arguments.gatewayname).init(variables.ins
> tance.dsn)
> ;
> }
>
>
>
> on application start
>
> application.gatewayfactory =
> createobject("component","gatewayFactory").init(mydsn,myothervariables
> );
>
>
>
> in page:
>
> objGW = application.gatewayfactory.load("someObjGW");
> objGW.getEmployees();
>
>
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
> Behalf Of Jason Davey
> Sent: 09 September 2005 08:58
> To: [email protected]
> Subject: RE: [CFCDev] Method parameters vs method names WAS: When to
> use the THIS scope for a ColdFusion Component?
>
>
> Barney:
>
> I like the idea of creating methods with no parameters e.g.
> getGasRemaining() thereby abstracting the interface from the caller.
> This raises the following question. In the case where you are calling
> a Gateway method (SQL SELECT calls), how do you create a clean method e.g.
> getEmployees() without passing in a datasource parameter? E.g.
> objGateway.getEmployees(APPLICATION.DataSource)
>
> My answer: the gateway component itself has a property called
> "datasource"?
> Therefore, would the following be the right approach?
>
> objGW = CreateObject("component","someObjGW").init();
> objGW.datasource = APPLICATION.DataSource; objGW.getEmployees();
>
> Inside the Gateway component, there is the following:
>
> The component 'setter / getter' functions...
>
> <!--- set --->
> <cffunction name="setDataSource" access="private" returntype="void"
> output="false">
>
> <cfargument name="datasource" type="string" required="true" /> <cfset
> variables.datasource = ARGUMENTS.datasource /> </cffunction>
>
> <!--- get --->
> <cffunction name="getDataSource" access="private" returntype="string"
> output="false">
> <cfreturn variables.datasource />
> </cffunction>
>
>
> And then the getEmployees function...
>
> <cffunction
> name="getEmployees"
> access="public"
> returntype="query"
> displayname=""
> hint="returns a list of all employees"
> output="false">
>
>
>
> <cfquery name="qryGetEmployees"
> datasource="#THIS.datasource#">
>
> SELECT *
> FROM people where category = 'employee'
>
> </cfquery>
>
>
> <cfreturn qryGetEmployees />
> </cffunction>
>
> Jason D
>
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Barney Boisvert
> Sent: Tuesday, August 30, 2005 4:12 PM
> To: [email protected]
> Subject: Re: [CFCDev] Method parameters vs method names WAS: When to
> use the THIS scope for a ColdFusion Component?
>
> Yes, because that changes the interface, which will break existing code.
> You could make it an OPTIONAL parameter that defaults to 'gallons',
> and be safe, but I don't like the idea of passing in parameters that
> dictate behaviour to methods. I much prefer to have a distinct method
> for each distinct behaviour, if that makes sense.
>
> To take a different tact, the standard definition of a getter is a
> "Zero argument method that returns the value of an object's property",
> not a "one argument method that returns the value of an object's
> property, based on some dynamic calulation that relies on the passed
> argument". So, you no longer really have a vanilla getter. Note,
> however, that neither definition precludes you from doing some wholly
> internal computation to arive at the returned value; it's the external
> dependancy (the passed parameter) that differentiates them.
>
> Subtle points, but enough to make me take the "add methods" route.
>
> cheers,
> barneyb
>
> On 8/30/05, John Ottenbacher <[EMAIL PROTECTED]> wrote:
> > Greetings,
> >
> > I am trying to transition from procedural development to OO development.
> >
> > I'm curious, in the example given is there anything 'wrong' with
> > adding a parameter to GetGasLeft()? It would have to be optional
> > and default to the original unit of measurement so as not to break
> > existing
> code.
> >
> > getGasLeft("GALLONS")
> > getGasLeft("METERS")
> >
> > Thanks,
> >
> > John
> >
>
> --
> Barney Boisvert
> [EMAIL PROTECTED]
> 360.319.6145
> http://www.barneyb.com/
>
> Got Gmail? I have 100 invites.
>
>
> ----------------------------------------------------------
> 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).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> 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).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> 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).
>
> CFCDev is supported by New Atlanta, makers of BlueDragon
> http://www.newatlanta.com/products/bluedragon/index.cfm
>
> 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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
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).
CFCDev is supported by New Atlanta, makers of BlueDragon
http://www.newatlanta.com/products/bluedragon/index.cfm
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
