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]
