My bad. I missed one key part of the thread to which I was replying. "Instance data". I assumed a getter like getName() which pulled the name from a DB was included in the 'not to do' list.
After reading this everlasting thread I agree full heartedly. Adam Wayne Lehman Web Systems Developer Johns Hopkins Bloomberg School of Public Health Distance Education Division -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sean A Corfield Sent: Monday, September 15, 2003 12:22 PM To: [EMAIL PROTECTED] Subject: Re: [CFCDev] Getters and Setters WAS: DB and OO question On Friday, Sep 12, 2003, at 08:47 US/Pacific, Adam Wayne Lehman wrote: > By 'automatically' creating assessors for the core object you are > making > the object as flexible as possible. I don't agree with this. You're simply breaking encapsulation by doing this and exposing the internals of the object. > Which is where I have to disagree > with Holub when he wrote: "We do know how we will use the classes, you > don't have to waste your time building unnecessary flexibility." He means on a business level - if a class is coherent and loosely coupled, and implements its business model well, then it will be as flexible as the business rules will allow it to be. > Although I may know how _I_ will use the classes I cannot determine how > any other developer will now, or in the future. Adding unnecessary set/get methods will likely encourage future developers to misuse your classes... > So my question is, how do I add displayUser() to my core object without > preventing flexibility? Does anyone disagree with the value I'm putting > on flexibility? According to the business model, is it the object's job to display itself? Or is that the job of the UI? Is the application complex enough for this distinction to matter? If the business object is closely tied to the way it displays, separating may be the wrong thing to do. Good application design is hard so we shouldn't expect to get it right straight away - nor should we expect there to always be just one way to solve a problem. There's no one true way, just a series of tradeoffs. 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] ---------------------------------------------------------- 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]
