This question has already been debated in struts-dev in Nov; 2000.
Unfortunately, online archive is not available for this thread.
I join a copy of Craig McClanahan response.
Cedric
"Craig R. McClanahan" wrote:
> Cedric Dumoulin wrote:
>
> > I would like to know why Struts uses base classes rather
> > than interfaces with default implementations.
> >
> > As example, I am interested to know why ActionForm is an abstract
> > class rather than an Interface (as in previous Struts versions).
> > Could you explain me the reasons ?
> >
>
> >From my perspective, there are a couple of reasons that ActionForm is
> turning into a class instead of an interface:
>
> * EXTENDABILITY. Adding a new method to an ActionForm interface
> (in some future version of Struts) will cause any application's form
> beans to become incompatible -- unless they happened to implement
> the convenience base class that was provided. With ActionForm
> as a class, the only beans that are incompatible are those who have
> a method name clash.
>
> * CORRECT USE. If ActionForm were an interface, you would be
> tempted to use existing data beans as an ActionForm. IMHO,
> ActionForm is part of the presentation layer (for reasons that have
> been discussed on the mailing lists previously) and the provided
> APIs should encourage using it that way.
>
> >
> > For my point of view, it seem that using base classes
> > rather than interfaces close some doors in this case : With a base
> > class, you "have to" extends the class, which forbid any others classe
> > inheritances. But, an ActionForm is used to expose properties from, lets
> > say, business logic objects (BO). So, you must implement your action
> > form with a delegate of your BO. If later you modify your BO
> > (customization for a new client), you need to modify your action form.
> > This will not happen if your action form can extend the BO (or its data
> > representation), and use a delegate for the ActionForm interface. So,
> > why closing this possibility ? Do I miss something ?
> >
>
> Consider that your business object has property setters that match the form
> fields (a very typical case). Do you have any internal validation in your
> setters to, for example, disallow a null or zero-length value for a required
> field? If you do, then this bean is *not* appropriate for use as an
> ActionForm - because the API contract for an ActionForm is that it
> faithfully represents the input that the user submitted (so that it can be
> reproduced), whether or not that input is semantically valid.
>
> There are additional problems with the fact that -- especially if you use
> EJBs as your business objects -- you are starting transactions (and
> potentially locking resources in the underlying database), when the user may
> never come back. Applications will scale better if you don't start
> initiating the database transactions until a semantically valid input has
> been accepted.
>
> >
> > Cedric
>
> Craig McClanahan
