>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.
This speaks to object cohesion. Why should your object have to care how it
will be used? In fact, why should the object have any idea about the
outside world at all?
>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.
>...
>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
>
><cfsavecontent variable="userxml">
><user id="#User.getId()#">
> <firstname="#User.getFirstName()#"/>
> <lastname="#User.getLastName()#"/>
></user>
></cfsavecontent>
>
>or
>
><cfset userxml = User.getXmlRepresentation("shortFormat")>
In general, I'd argue that the opposite is true - that most of the time this
approach will _add_ methods. It's a user object. It shouldn't care that it
will be used to generate XML. It shouldn't even care that it will ever be
persisted in any way. By this argument, I should try to predict everything
that anyone will ever want to do with my object and provide a convenience
method for it. If you're going to go this route, why stop with
getXmlRepresentation? Why not add a getIniFileRepresentation,
getJsonRepresentation, getBinaryRepresentation,
getXmlRepresentationInSpanish, etc? That's an awfully slippery slope.
>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.
And I'm arguing that in general, if you're telling an object to do something
*outside it's primary scope of function*, that it's a bad thing since it
breaks cohesion. And in my estimation, cohesion is far more important than
convenience. Asking an object to do something for you is an extremely good
idea in many situations - Service and Persistence objects, for example are
used almost _exclusively_ by asking them to do things (such as
Gateway.SaveUser(user)). AND THIS IS PRECISELY WHERE THAT LOGIC BELONGS -
in a separate service layer. Be that service persistence, formatting, or
display, it belongs in a separate entity, not in the object itself.
We can go around in circles about this all day, but the fact is that the
"ActOnThyself" pattern described in that article is a far more niche pattern
than the article would lead users to believe. The number of other
principles that it violates, as well as the fact that there are many other,
and in my estimation *clearer/broader/more common/better * patterns for
dealing with the same issues limit this specific approach to solving a very
tiny set of problems really makes it trivial in all but the most specific
situations.
Roland
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to
[email protected] 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/[email protected]
