So, you're saying a Person should have something like: personalDetails = person.getPersonalData();
and then I'd reference, in my HTML/persister/etc: personalDetails.firstName personalDetails.lastName ?? If so, I'm not sure I understand the benefit. I still need to know what keys will be in my personalDetails struct, and now I lost the handy auto-documentation of the components meta data. It also prevents something like: person.getFullName() where that method does a concatenation of the firstName and lastName (and possibly middleName, if it's not blank) private attributes of my Person instance. Or, am I missing the boat here? > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Sean A Corfield > Sent: Thursday, September 11, 2003 5:04 PM > To: [EMAIL PROTECTED] > Subject: Re: [CFCDev] Getters and Setters WAS: DB and OO question > > > On Thursday, Sep 11, 2003, at 14:18 US/Pacific, Nathan Dintenfass wrote: > > 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. > > I've always said not to expose your instance data directly - no 'this' > scope (no 'public' data in other languages). However, that doesn't mean > that you should simply write a public get/set method for every > attribute! > > > 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. > > Your Person and PersonPersister class are closely coupled by > definition. It is reasonable to use something like a Memento design > pattern to transfer data between the two classes as a single unit > rather than making multiple method calls. Apart from anything else, > that reduces the amount of code changes required should you add a new > field (you don't need to add new get/set methods). It also sits well > with the idea of having variables.instance (or variables.memento) as a > struct containing the lump of data you might want to pass to the > persister. > > Note that in C++, you'd probably side-step this entire issue by > declaring the persister as a friend of the class that it persists (an > old joke in C++ circles: "Definition of a friend? Someone who has > access to your private parts"). > > > I just KNOW that Sean isn't proposing public data members > > (personInstance.firstName), is he? ;) > > You KNOW correctly! > > 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]
