Re: News for Java?
On 09-01-2011 00:09, Arved Sandstrom wrote:
On 11-01-08 09:46 PM, Arne Vajh?j wrote:
On 05-01-2011 05:33, Arved Sandstrom wrote:
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.
It is certainly a problem that could happen.
But does it happen?
Bean developer providing an unnecessary setter. Client code
developer unnecessary wanting to use the setter. Client code
developer giving up because of no setter instead of doing one
of 1) getting the bean changed 2) call one or more business methods
to change state 3) fallback to reflection. The changing of
state actually resulting in a problem.
Each is quite likely. But combined??
I don't think I have ever seen it. I don't think I have ever
heard or read about it.
I have to admit that I didn't quite follow the specific chain that you
laid out. But I'll tell you what _is_ not uncommon: the changing of
state, through a setter use, resulting in a problem. This can happen any
time that setters are provided without understanding what the class
invariants are, and/or the setters do not enforce class invariants (*)
(**).
This isn't rare, it's common. I honestly don't know what it is that
you've never seen or read about, but if you've never seen defects that
were caused by a setter putting an object into a logically inconsistent
state, then you haven't seen a lot of code.
Seen/read about setters causing problems. And I think that I have seen
quite some code.
But you added something important here "setter putting an object
into a logically inconsistent state".
If we are talking about setters that can put the object in an
inconsistent state, then I completely agree with you that
this type of setters should be avoided.
But in my experience that is a small fraction of beans,
Even pretty bad developers usually have some reason to want to
call a certain setter.
Yeah, they do have a reason: someone else made the setter available, and
because a lot of the logic that ought to have been inside the object
existed out in business logic, they followed the path of least
resistance. It's a lousy reason, but it's a reason.
I start to think that your point of view is related to the
criticism of the practice of putting logic in on class and
putting data in another class with only getters and setters.
Arne