How to re-use existing classes in JSP/JavaBeans/Servlets

[Wendy Smoak]

Well, of course "no scriptlets allowed" means "JavaBeans required".
It's no surprise that an artificial restriction requires an artificial
solution. Why did you introduce that restriction, do you encounter
many cases where there is a real restriction against using scriptlets?

Ahhhh, now I get it! You think JavaBeans have no benefits, and I think
scriptlets are ugly and difficult to maintain. It's a religious debate,
we'll just have to agree to disagree, and end it here.

 

[thecrow]

Ahhhh, now I get it! You think JavaBeans have no benefits, and I think
scriptlets are ugly and difficult to maintain. It's a religious debate,
we'll just have to agree to disagree, and end it here.

So it's based on nothing but personal preference then? Nothing
objective about it? That's a disappointment.

 

[thecrow]

I found a satisfactory answer for anyone approaching this question from
the same angle as me. My basic issue with JavaBeans was that the
practice "smells of accessors". I don't subscribe to the "accessor
methods are evil" belief, not in the literal sense anyway, but I do
think that having too many accessors could be a sign of a flawed
design. And in the case of JavaBeans, if you want to delegate to your
interface designers, you have to specify a lot of setters and
getters... to a certain naming convention, no less, which I found to be
a big red flag.

This article explained it very well:
http://www.javaworld.com/javaworld/jw-09-2003/jw-0905-toolbox.html.
Written by Allen Holub, it about the pitfalls of abusing getter and
setter methods. I found his comment interesting, that accessors exist
mainly for the purpose of hooks into higher level automation and
testing tools. It's important to note that this title is not intended
to be taken literally, it is just a way to start a conversation. So
the rest of this post quotes from that article, entitled "Why getter
and setter methods are evil.":


You might object by saying, "But what about JavaBeans?" What about
them? You can certainly build JavaBeans without getters and setters.
The BeanCustomizer, BeanInfo, and BeanDescriptor classes all exist for
exactly this purpose. The JavaBean spec designers threw the
getter/setter idiom into the picture because they thought it would be
an easy way to quickly make a bean-something you can do while you're
learning how to do it right. Unfortunately, nobody did that.

Accessors were created solely as a way to tag certain properties so a
UI-builder program or equivalent could identify them. You aren't
supposed to call these methods yourself. They exist for an automated
tool to use. This tool uses the introspection APIs in the Class class
to find the methods and extrapolate the existence of certain properties
from the method names. In practice, this introspection-based idiom
hasn't worked out. It's made the code vastly too complicated and
procedural. Programmers who don't understand data abstraction actually
call the accessors, and as a consequence, the code is less
maintainable. For this reason, a metadata feature will be incorporated
into Java 1.5 (due in mid 2004). So instead of:

 

[thecrow]

Ugh! I read that a while back, and I did not think he made much sense.
I suspect that is because he is using different definitions of "accessor",
"getter", and "setter" than I do (and the JavaBeans specification does).
In any case, since those terms are critical to his thesis, he should have
defined them.

Holub says:

Getter and setter methods (also known as accessors) are dangerous
for the same reason that public fields are dangerous: They provide
external access to implementation details.

This is not true, assuming my (and the JavaBeans) definition of accessor.
Accessors provide external access to the *properties* of a component, not
its *fields*. In some (and perhaps many) cases, a property is implemented
using a field, but that is just an implementation detail that is subject
to change.

As they are most often used, getters and setters are nothing but
pass-throughs to properties implemented as fields. The article was
directed mainly against that practice, and if you read the rest of the
article you can see that he mainly writing against the abuse of getters.

 

[John McGrath]

As they are most often used, getters and setters are nothing but
pass-throughs to properties implemented as fields. The article was
directed mainly against that practice, and if you read the rest of the
article you can see that he mainly writing against the abuse of getters.

That is the way he frames the argument, which is very misguided, IMO.

There is nothing at all wrong with using accessors, and there is also
nothing wrong with writing accessors that simply set or get the value of a
field. The real issue is how we design an appropriate public interface
for an object.

It is true that some people tend to design an interface by thinking about
the implementation, and then expose those details as properties. That is
certainly not the right way to do it.

But given that they have done that, there is nothing wrong with writing
accessors for those properties. The error was choosing those properties
in the first place, not in creating accessors.

And if you design an interface with a reasonable choice of properties,
there is nothing wrong with writing accessors for those properties.

In short, there is nothing wrong with accessors. Holub has chosen the
wrong villain.