Re: News for Java?
Arved Sandstrom wrote:
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.
Those are true statements.
The cure for this is education - programmers need to know what "class
invariants" are, for example. Otherwise they won't enforce them.
For me the key is that 'getX()' and 'setX()' are exactly attributes, and
therefore should exhibit no behavioral contracts. I don't model them as methods.
There are frameworks and other situations, as with JPA, where the framework
objects must have mutable attributes. Such objects must be contained,
limiting the number of actors on them and so reducing the dangers. For JPA,
entities are just entities in the program model - and of course one eschews
peeking into their persistence behaviors from above.
Objects that use mutable objects can enforce invariants around those uses -
again assuming the programmer is sensitive to invariants and asserts them.
Arved Sandstrom wrote:
Don't get me wrong - I'm not saying setters (or getters) are intrinsically bad.
I'm simply saying that you put them in with considerable care.
Much more care than is evident in the majority of published code.
Another underused padlock is 'public final' for accessors/mutators
(accemuters?). The overarching principle is, as J. Bloch's /Effective Java/
(2nd ed.) puts it, "Item 17: Design and document for inheritance or else
prohibit it".
--
Lew
Ceci n'est pas une pipe.