Two things that have helped me before are:

1) keeping the "is a" and "has a" relationships in mind when building/using 
objects.  If I want to use a piece of functionality in my object, than that 
object either "is" the type of thing I need, or it "has" it among it's 
properties.  If I have to dip into other scopes or arbitrary classes to achieve 
my desired results, something is wrong with the design I need to step back a 
bit and rethink things.

2) sometimes "dumbing down" the logic in #1, into real-world things helps 
determine if the design is correct or not. If myCFC1 and myCFC2 are both 
automobiles, I wouldn't have myCFC1 use myCFC2's method for startTheEngine(), 
that doesn't make sense.  So maybe I need some sort of fa�ade or proxy that 
"has" all of my automobiles stored in it, so things are encapsulated better.  

Hth,
Nolan




Nolan Erck
Web Developer/Programmer
Schools Financial Credit Union
(916) 569-5409 Office
(916) 569-2024 Fax
www.schools.org

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nando
Sent: Wednesday, June 01, 2005 10:26 AM
To: [email protected]
Subject: RE: [CFCDev] Accessing another CFC's methods

Andy,

It can be a little confusing at first how to get CFC's to play together if
you haven't much experience programming using an object oriented approach.
>From a procedural perspective, the question can arise "What's the sense of
encapsulation if it prevents objects from working together???!!"

The "trick" is in learning how composition works when you work with CFC's.
Basically speaking, composition (and inheritance) group CFC's together
within the same encapsulation boundary so they CAN work together. Once you
get the hang of it, you've got a whole bunch of options and variations to
choose from, but the basic theme remains the same, if 2 CFC's need to work
together, figure out the best way to form a "working group" so they can.
This is what OO patterns are about, more or less.

For instance, in your example, myCFC2 could be instantiated or passed into
myCFC1. Or ... you could create another CFC, myManagerCFC, and instatiate or
pass into Manager both my1 and my2. Then all your calls from within your app
would be to Manager, and within Manager, your functions would call my1 and
my2 to get things done. In this way, Manager would be acting as a facade.

There are many other variations once you get into this, but the big shift in
moving from procedural programming into object oriented programming (and
that's what you're doing if your going to do it "with out going to the
application scope" ) is learning how to work with encapsulation so it helps
you, rather than gets in your way.



-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Andy Jarrett
Sent: Wednesday, June 01, 2005 2:55 PM
To: [email protected]
Subject: [CFCDev] Accessing another CFC's methods


Hi there,

I have several CFC's in my app which i init into the application scope.

e.g. application.mycfc1 and application.mycfc2

If i want a method from mycfc1 from mycfc2 then i use the following code

<cfset usersName = application.myCFC2.getUsersName(id) />

I just wanted to check this is a good way of doing this? or is there
another i.e. with out going to the application scope?

Cheers

Andy J


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




The information contained in this e-mail is confidential and may contain 
privileged information exempt from disclosure under applicable law. The 
information is intended only for the use of the individual or entity to which 
it is addressed. If you are not the intended recipient, employee, or agent 
responsible to deliver it to the intended recipient, you are hereby notified 
that any use, dissemination, distribution, or copying of this communication is 
strictly prohibited. If you have received this e-mail in error, please delete 
the message from your computer and immediately notify the sender by telephone 
(you may call collect) at 916-569-5400 or by e-mail to [EMAIL PROTECTED] Thank 
you.


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


Reply via email to