> So you'd deprecate that method, and then add getGasLeftGallons() and
getGasLeftLitres() or something
I know its only an example off the top of your head, but this does change
the interface! So I can see why John would question the benefit.
Heres my take on the example - off the top of my head (feel free to pick
holes in it...)
car.gas returns a int, so then the presentation layer has to decide wether
its litres or gallons.
and its just a variable name, so all it can really ever do is return a
variable.
car.Gas() could at first only return a variable as well, but then when your
app grows, you have the option make it call several other functions within
itself. which makes the app more flexible.
so in the future, car.gas() might actually do something like:
var fuel =
math.convert("liquid","metric",country.getLiquidMeasurement(),gasamount);
return i18n.formatLiquid(fuel,country.getISOAlpha3());
all that, and your presentation layer is still only calling car.gas(), no
need to change anything except the contents of the function.
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of John Farrar
Sent: 30 August 2005 03:36
To: [email protected]
Subject: RE: [CFCDev] When to use the THIS scope for a ColdFusion
Component?
That sort of make sense. (But the calling code has to know the object is no
longer reporting gallons also... isn't that a violation of the encapsulation
concept?)
The second example has merit... since age is always relative to the time
checked. So unless you could have a variable that reported like a method
there would be an issue.
Thanks....
John
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Barney Boisvert
Sent: Monday, August 29, 2005 4:19 PM
To: [email protected]
Subject: Re: [CFCDev] When to use the THIS scope for a ColdFusion Component?
What if the units in the DB change from gallons to litres? You don't
want getGasLeft so start returning a value 3.8 times larger than
expected. So you'd deprecate that method, and then add
getGasLeftGallons() and getGasLeftLitres() or something. You don't
get that protection with instance variables, because as soon as the
switch happens, the instance variable's semantics change, and with no
indication.
Another example is getAge(), because you very likely aren't storing an
'age' variable, but rather than 'dateOfBirth' variable that needs
computation. But the calling code shouldn't care (or even be able to
tell); that's encapsulation.
Autogenerated get/set methods aren't any more helpful than just
exposing the raw data members. The encapsulation only comes when
they're actually encapsulating something, usually a conversion from
the publicly exposed properties to the actual internal representation.
cheers,
barneyb
----------------------------------------------------------
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]
