Re: News for Java?
Arved Sandstrom wrote:
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.
Arne Vajh??j wrote:
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.
In general terms, one uses settable attributes where the client code needs to
control state of the API object. Arne's use case fits that scenario, as do
I/O connections, other resource handlers, messaging, proxies and others.
The designer must think carefully about what constitutes observable or
settable state for a library type. An XML parser's client, for example, might
set a document source for the parser and retrieve parsed document objects.
Other parser state is not observable to the public (one trusts).
Good implementations for many types involve setting immutable public state at
construction. Without losing sight of the distinction between a constructor's
responsibilities and methods' responsibilities, the designer ties the
handler's lifetime to the lifetime of the captured state. Such a type will
sport no attribute mutators, only accessors.
Correct use of this technique, which I'm quite certain many forum participants
know well, rests on careful thought about the issues Arne and Arved bring up.
--
Lew
Ceci n'est pas une pipe.