On 11-01-04 10:12 PM, Arne Vajh?j wrote:
On 04-01-2011 15:05, markspace wrote:
On 1/4/2011 11:10 AM, Chris Uppal wrote:
I dislike "accessors" more -- much more -- than I dislike
pass-by-reference-to-variable parameters.
Pass-by-ref[etc] is an invitation to abuse, but isn't all that often
abused
simply because it isn't often "needed"; but accessors are more like an
/order/
to abuse -- they teach you wrong by their mere existence.
The "accessors of evil", as I think someone once said.
Huh, I don't think I understand. I don't recall hearing a sentiment like
this expressed before. At worst, Java's accessors (getter/setters) have
a vertical problem where a code listing is longer than it strictly needs
to be.
But that's the worst I've heard about them. Everything elese I've heard
says that accessors are a good way of encapsulating your code.
What's the argument advocating avoiding accessors?
One well known argument is that the object should expose
real methods with business logic and let those change the
state instead of letting the calling code change whatever
it wants.
It has some theoretical merit. But from a practical point
of view it is bullshit. There are no real problems having
setters.
There are no real problems having setters??? Come on, Arne, are you just
being rambunctious these past few or what? Leaving aside getters
completely (and all the real-world problems associated with over-use of
those), every setter on a class introduces a vulnerability: it's an
additional worry when you reason about what external code is modifying
instances of that class.
You're either advancing the argument that the majority of coders are
sparing and conservative when it comes to providing setters - which I
sure as hell haven't seen - or that the majority of coders are sparing
and conservative when it comes to using the setters that have been so
helpfully provided for them...and I haven't seen that general discipline
either.
Either of _our_ observations are just single data points, so either one
of us could be mistaken. But until I see studies saying I'm wrong, if I
think that the idea that setters are problematic has theoretical merit
(which you tepidly agreed with), then I'll assume it has practical merit
also.
Bean developer providing an unnecessary setter. Client code
developer unnecessary wanting to use the setter. Client code
to change state 3) fallback to reflection. The changing of
Each is quite likely. But combined??
I don't think I have ever seen it. I don't think I have ever