Never underestimate the power of the Dark Side! :)
Jonathan Locke wrote:
i imagine setVisible came from me. just because setters are evil and you
should avoid them when you can does not mean you should not use them when
you need them.
Matthijs Wensveen-2 wrote:
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]
--
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]
