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]

Reply via email to