Question though - what if you need a getter, and it _currently_ just
does a blind return, but you set it up so that in the future if you need
to do processing, your clients will not need to change their code?
Instead of focusing on the implementation of the getter itself, consider whether it really needs to be part of the class API. Let's suppose that we have a person class and in our application we're very interested in the person's age. So we add getAge() because it is required by the business model. Let's suppose that we initially have people entering their actual age, so getAge() simply returns that. We quickly realize that we really need people's birth date instead so we update person to have a birth date and remove age - and modify getAge() to calculate the age based on the birth date.
That's your scenario but focus on the API and the methods, not on the attributes.
When you're building a model, e.g., in UML, you identify the nouns (classes) and verbs (methods). The actual attributes of a class are 'merely' implementation artifacts.
Sean A Corfield -- http://www.corfield.org/blog/
"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 word 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
