Of course I have a few things to learn, and I hope I never stop
learning. The article you provide is interesting.
My opinion is that for domain entity objects, getters and setters are
certainly not evil. For classes that are more service-like, getters and
setters could be useful but should be considered well. In case you
choose not to have a getter and a setter one should be extra careful
when choosing method names. I usually expect a setVisible method when
there is also an isVisible method. Immutable classes, or classes with
read-only properties can choose to only provide a getter for some
properties. But if a method like isVisible is intended to be overridden
something like public boolean visible() might be better. But I guess
this is also a matter of style and taste.
As for Component.set/isVisible, I like that I can do both, even if it
gives me the possibility of ambiguous code like new Component()
{isVisible() {return true;};}.setVisible(false) or something like that
(it is actually not ambiguous at all of course, but you do have to read
extra careful). So whatever reason you (core devs) originally had for
providing a setter, I am thankful for that.
Matthijs
Jonathan Locke wrote:
i think you may have a few things to learn and it is not exactly
controversial to prefer immutability or encapsulation... setters break
encapsulation and i think it is safe to say decades of experience with
object systems is on my side, including industry luminaries like:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html
Matthijs Wensveen-2 wrote:
Jonathan Locke wrote:
true.
in the isVisible impl you could lazy-init cache a transient Boolean until
end request where you set it null.
setters are evil.
..but it's good to have choice. *And* setVisible is not a normal setter,
because it returns the component, which makes it easy to add an
initially invisible component like: add(new Label("profanity",
"[EMAIL PROTECTED]").setVisible(false));
Also, with is/setVisible you van use the component with a propertymodel
to have some other component toggle the visibility of another component.
This way you have the best of both worlds.
A little off-topic: It scares me a little when core developer make bold
statements like: "setters are evil" and "I wouldn't mind final was the
default in java". Maybe I'm just being paranoid here...
Matthijs
egolan74 wrote:
Yes but ...
isVisible may be triggered several times, while setVisible should only
be
called once (say if I do it only once after creating the component).
Usually I prefer the state driven way, but what if the logic has a lot
of
overhead?
Jonathan Locke wrote:
isVisible is generally better imo because it is state driven. if you
push instead of pull, the state can get stale.
--
Matthijs Wensveen
Func. Internet Integration
W http://www.func.nl
T +31 20 4230000
F +31 20 4223500
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
