struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <>
Subject Re: Interfaces vs base classes
Date Tue, 14 Nov 2000 13:35:01 GMT
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

View raw message