This article is admittedly tough to swallow. Holub seems to be writing on his personal opinions and philosophy of OO and applying it globally to universal OO design. I'm having a tough time applying it to the Cold Fusion environment.
One of his strongest points is 'what happens when you change a data type'. Absent of an interface, your application will need to be updated wherever the getter is called. This is obviously not ideal. So rather than call getUser() in order to display user information, you call displayUser(). Now were asking the object with the data to do the work. My issue, aside from the fact that now the object is not only responsible for retrieval and manipulation of data, but now it's responsible for display as well. Now I can't use this object in another application. I can break it up into three parts: The application, the interface and the core object. I feel that the core object can be over populated with assessors without problem. I could change data types and what not, and only the interface would need to be updated to accommodate. The application is safely separated and will continue to call displayUser(). By 'automatically' creating assessors for the core object you are making the object as flexible as possible. 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." Although I may know how _I_ will use the classes I cannot determine how any other developer will now, or in the future. I can see that flexibility is unnecessary for the desktop environment, but in our case of building distributed web applications, flexibility is value. It means that another developer I may never meet can write an interface for my user object and _never_ have to modify the object to meet their needs. Back to the original test of changing a data type. Now only displayUser() will need to be updated to handle the different data type. Rather than countless instance within the application. So it's just minimized, not eliminated. 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? 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 Brad Howerter Sent: Friday, September 12, 2003 10:33 AM To: '[EMAIL PROTECTED]' Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question I disagree that that was his point, but you're close. His point is that we should rarely create getter/setter methods. He doesn't care whether you've automatically created them. But I don't agree with Holub. I think the overuse of them is the problem, not their creation. And one way to avoid their overuse is to have the objects display themselves. But Holub and Corfield say we should put methods that do that in a different layer. Why? -----Original Message----- From: Hal Helms [mailto:[EMAIL PROTECTED] Sent: Friday, September 12, 2003 1:31 AM To: [EMAIL PROTECTED] Subject: RE: [CFCDev] Getters and Setters WAS: DB and OO question Holub's point is that the *automatic* creation of *public* getters and setters is a problem. It's not that they're somehow evil; it's that we should make sure that we can't let the object do whatever work we might be wanting the info for. It's a good point, but it's all too easily warped into "Don't use getters and setters." Hal Helms See halhelms.com for classes in... Java for ColdFusion Programmers Fusebox 4 Mach-II OO Applications with CFCs -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nathan Dintenfass Sent: Thursday, September 11, 2003 5:18 PM To: [EMAIL PROTECTED] Subject: [CFCDev] Getters and Setters WAS: DB and OO question I got that same thing from the article, but that goes against everything the OO folks in CF-land (Sean, foremost among them) has been preaching. So, frankly, I'm confused as to what is being suggested here. Is the rule being espoused that getter and setter methods are only for "public" methods that an end-developer will use? I could understand that, but that's not what I'm reading on these posts and in Sean's blog. If I've got a Person and a PersonPersister (to use someone else's example), and I say something like: personPersisterInstance.savePerson(personInstance) Should the PersonPerister not call the getFirstName(), getLastName(), etc. methods from Person, much the way I would have the the PersonRender custom tag might do? I just KNOW that Sean isn't proposing public data members (personInstance.firstName), is he? ;) > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Brad Howerter > Sent: Thursday, September 11, 2003 1:44 PM > To: '[EMAIL PROTECTED]' > Subject: RE: [CFCDev] DB and OO question > > > I just read Holub's article. Applied to ColdFusion MX, I think it is > a good argument to encapsulate more of your data access within CFCs, > including writing methods to do display instead of retrieving values > to display on your own. Once you put the display methods in your > CFCs, then you can dispense with the setter/getter methods. Holub > says "Draw Thyself". > > ---------------------------------------------------------- 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] *** The information in this email is confidential and intended solely for the individual or entity to whom it is addressed. If you have received this email in error please notify the sender by return e-mail, delete this email, and refrain from any disclosure or action based on the information. **** ---------------------------------------------------------- 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]
