Thanks for taking some time to answer my "naiive question.
>
> I think you've really got two threads of questions here, so
> let me try to
> address them separately.
>
> (1) Why use getXxx and setXxx for properties?
>
> This is a general design pattern called JavaBeans, and you
> will find it very commonly implemented.
Yes, I know. The question that I was asking though, was why implement the
JavaBeans design pattern here? A persistent class in a web setting does not
have to be a bean. A ServletContext or a HttpSession is not. Attributes are
set and retreived along the lines I indicated. Although JavaBeans have been
one way of getting persistence, I see little reason (yet) why the ActionForm
should be modeled as such.
> * Information hiding (for example, how do *you* know that a
> particular getter method returns a simple property value,
> and doesn't do some on-the-fly calculations every time?)
Beside the point, information is as hidden with the simpler interface.
> * Introspection (so that development tools can recognize the
> design patterns and provide a nice GUI user interface for
> creating and connecting beans).
Nothing prevents the programmer from adding getter/setter methods for the
Action class by extending the ActionForm class.
> (2) Why ActionForm versus just ordinary beans?
My question was why ActionForm is modeled on a bean, not why it should be
the base class. In the end, the design of a class should depend on what
designers think it should do. The point of departure in my philosophising
was that ActionForm should do little beyond conversions, validations and
such.
Jonas
