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]
