I've been watching this thread with interest, because I think that the
dependency injection pattern is a solution to the problem that actually
fits CF's shortcomings. Since there's no "import" of libraries within a
CFC, one is either left to provide the library dependency during
instantiation, or require that your CFC goes and locates the library
itself. The first is obviously the better solution, however I've found
that it can get difficult to maintain as the number of dependencies
increase.

Thus, when I have a "util" style CFC that is of interest to another
CFC, I usually have a setSomeUtil(org.utils.someUtil u) method to inject
that dependency. Sure, there are some thread safety risks at
instantiation time to be concerned about, but coded properly they can be
mitigated.

The nice thing is that since my "container" is managing my
dependencies, adding a setSomeUtil(org.utils.someUtil u) method is all
that needs to be done to bring in a library (provided the container
knows org.utils.someUtil). I make don't make any changes to code that
"creates" cfcs. Also, when the time comes to swap org.utils.someUtil
with a different implementation, I don't have to change a single line of
code.

-Dave Ross



On Apr 3, 2005 5:07 PM, Sean Corfield <[EMAIL PROTECTED]> wrote:
> On Apr 3, 2005 1:29 PM, Adrocknaphobia <[EMAIL PROTECTED]>
wrote:
> > Right now, during the init() of the main CFC I'm loading
oracle.cfc
> > and copying the methods to the base cfc and so forth for any other
> > imports I'd like to do. Problem is that this is not very elegant.
> 
>  What's wrong with just instantiating the utility CFCs as data
members and
> accessing the (public) methods directly? Heck, what's wrong with
just
> <cfinclude>ing the file containing the raw UDFs into your CFC
(outside any
> methods), thus making them non-public members of your own CFC?
>  
> > extend these utlility cfcs in some sort of mind numbing chain of
> > complexity using... extends. Which, by the way, really sucks and
> > limits you from actually using extend properly.
> 
>  Correct. Inheritance is absolutely not the right approach for this.
-- 
>  Sean A Corfield -- http://corfield.org/ 
> Team Fusebox -- http://fusebox.org/ 
> Got Gmail? -- I have 50, yes 50, invites to give away!
> 
> "If you're not annoying somebody, you're not really alive."
> -- Margaret Atwood
> ----------------------------------------------------------
> 
> 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] 


-- 
Invite 50 Friends to Gmail!  Who has friggin' 50 friends!?


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