>Yep. And the example of display is a horrible one. Every
>time you want to
>add a new output device, you still need to add new renderers
>and you gain no
>actual benefit IMO. Not to mention a horrible lot of UI inconsistency.
>
Every time you want to support a new storage tech (database, XML,
whatever) you add a new type of DAO object. What's the difference?
>Besides, having an object provide so many functions is
>horrible in terms of
>tying to keep objects cohesive and encapsulated. If every
>object were to
>try to anticipate every action that it was going to be told to
>do, they'd
>all grow to be huge, functionally (un, non?) in-cohesive
>beasts. You'd now
>have your objects performing multiple unrelated tasks, which
>is just plain
>bad in almost every situation.
>
Which is why he makes a point of saying that accessors are the way to go
if you don't know how your objects are going to be used - kind of a
"suit yourself" approach.
I don't agree that this approach will always necessarily lead to much
bigger, "uglier" objects. Firstly because an object can delegate to
another object to perform a task rather than perform it itself.
Basically, i shouldn't have to care about how the task gets done (i ask
you and you do it, vs. i ask you and you get someone else to do it), as
long as it gets done and i don't have to do it myself. Keeps the code
nice and separate. Secondly because this approach can actually cut down
on the number of public methods in an object. Let's imagine that i have
to make a little xml packet with a user's info: which would you rather
do:
<cfsavecontent variable="userxml">
<user id="#User.getId()#">
<firstname="#User.getFirstName()#"/>
<lastname="#User.getLastName()#"/>
</user>
</cfsavecontent>
or
<cfset userxml = User.getXmlRepresentation("shortFormat")>
If my early cf code is anything to go by, i'm willing to bet that many
of us have unused getX() or setX() methods in our code - because
creating them is just a reflex (and with CFEclipse, it's a couple of
checkboxes).
>RenderThyself is just another example of a limited-use pattern
>that people
>have tried to over-apply.
Ignore the fact that we're using display as an example: this is more
about telling an object to do something versus asking an object to give
you information.
/t
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
cfcdev@cfczone.org with the words 'unsubscribe cfcdev' as the subject of the
email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting
(www.cfxhosting.com).
An archive of the CFCDev list is available at
www.mail-archive.com/cfcdev@cfczone.org
