Re: News for Java?
On 09-01-2011 20:04, Arved Sandstrom wrote:
On 11-01-09 07:01 PM, Arne Vajh?j wrote:
On 09-01-2011 00:09, Arved Sandstrom wrote:
[ SNIP ]
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".
I'd also mentioned that in another post in a related subthread in this
thread, and it's always been an implied subtext of my criticism of
careless accessors. But I hadn't explicitly mentioned it in previous
posts in _this_ subthread...one of the hazards of answering in several
different spots.
That is however _my_ chief complaint, not verbosity.
Then I would tend to think we are in violent agreement.
:-)
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,
I prefer not using the term "bean" unless the discussion is about
classes that must conform to the JavaBeans convention. I'm thinking
about classes in general.
As far as I'm concerned a class isn't a bean unless it's going to be
used in such a way that it's required to be a bean. Now, if it's a
non-bean that _looks_ like a bean, because the developer went crazy
providing getters and setters, that's when my nose starts telling me
that things are maybe smelly.
Even outside classic beans there are cases where I think setters
are nice.
Like classes that need instruction on how to do things. Example: XML
parsers.
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.
"Related" is probably accurate; I wouldn't say that what I am trying to
express here is exactly that. There's no question, though, that if
someone is programming C in Java, using objects as structs and writing
procedural code, that a strong sign of that will be what you just
described. Objects that behave like structs are needed/useful when most
of the logic is in "procedural" classes.
Martin, in another reply to your last, stated that what you describe is
likely an OO anti-pattern. In my opinion it's not even OO - you may have
an object-oriented language available, but you've chosen to use the
langauge as if it's not OO. Strictly speaking I can't see that this is
innately wrong - if it's OK to write procedurally in FORTRAN then I
guess it's OK to do the same with Java. But it would be nice if people
didn't delude themselves that they were writing OO code when they're not.
If they want to program in Fortran they may be better of using
Fortran.
That would make it easier to get the correct skills assigned to
the project.
Arne