I agree, Patrick, that your idea is a fine one where possible. But are you
really suggesting that for every method that a Person object has, an
additional method exist to get their spouse to do it also? That's just not
viable.
Person
getCompany(): Company
getSpouseCompany(): Company
etc.
And what if the person has children? I know you don't want things like:
child1.getCompany(), child2.getCompany().
So, yes, you really do many times have to have things like
hal.getSpouse().getCompany().getStockPrice().
If I'm missing something, please let me know.
Hal
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Patrick McElhaney
Sent: Wednesday, October 26, 2005 11:07 AM
To: [email protected]
Subject: Re: [CFCDev] CFC return types
On 10/26/05, Hal Helms <[EMAIL PROTECTED]> wrote:
> Why not just have an isNull(propertyName) method rather than litter
> classes with hasSpouse, hasX, has Y?
Yuck. Yuck. Yuck.
The idea that you get a spouse from a person and then do something with the
spouse already violates the Law of Demeter. If you have to check if the
person has a spouse before calling getSpouse() you're probably asking the
client code to do something that should be encapsulated in person itself.
Instead of this:
<cfif person.hasSpouse()>
<cfset spouse = person.getSpouse()/>
<cfset spouse.foo()/>
</cfif>
You should work toward something like this:
<cfset person.fooSpouse()/>
<!--- in person.cfc --->
<cffunction name="fooSpouse">
<cfif structKeyExists(variables, "spouse")>
<cfset variables.spouse.foo()>
</cfif>
</cffunction>
Now the client code doesn't have to worry about using person incorrectly
(i.e. calling hasSpouse() on a person who is not married).
It doesn't have check preconditions or handle exceptions.
Back to Hal's question.
> Why not just have an isNull(propertyName) method rather than litter
> classes with hasSpouse, hasX, has Y?
Because if your class is littered wih hasSpouse, hasX, hasY methods, your
class is likely has a problem. An isNull(propertName) covers over the
problem, just as set(propertyName) and get(propertyName) methods cover over
the problem of public fields.
Although I suspect Hal knows that and he's just checking to see who's been
paying attention. :)
Patrick
--
Patrick McElhaney
704.560.9117
http://pmcelhaney.weblogs.us
----------------------------------------------------------
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]
