struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Szego" <>
Subject Re: Multi-page form
Date Wed, 11 Oct 2000 15:50:19 GMT

-----Original Message-----
From: Robert Leland <>
To: <>
Date: Thursday, 12 October 2000 12:19
Subject: Re: Multi-page form

>> >
>> > For what it's worth, I prefer leaving both as interfaces and providing
>> > ActionBase and ActionFormBase for people to inherit from should they
>> > to.
>> Believe me, I wish this were a reasonable path ... but it appears to me
that it
>> is not.
>> Consider the fact that, in the future, we want to enhance our notion of
what an
>> ActionForm does with some new optional functionality.  For a concrete
>> consider the desire to add a validate() method on a ValidatingActionForm
>> takes additional arguments to provide context information.
>Absolutely, there are other reasonable path. It is called 'Delegation'.  I
>this yesterday on the struts-dev group about delegation.
>If interested see
>An interface is not absolutely required. That is exactly how Sun got there
self in all
>sorts of trouble when they designed AWT in Java 1.0, They uses Inheritance
to extend
>their classes. When AWT shipped with Java 1.0 it was generally regarded as
one of the
>worst piece of code around. Then they started working with the people at
>and redesigned AWT to use delegation for their next version of AWT so by
version 1.2
>it was considered one of the best most extensible designs around, and they
did it
>with delegation.
Agreed. Delegation is just one of the strategies to use, but the fundamental
issue is one of "inheritance vs. composition". Peter Coad has some good
insights on when each is suitable (as do several others), but what it boils
down to is that you *very* rarely need inheritance, and most often should be
using composition instead if you want flexible, extendible, robust

Plenty more info, pointers and examples available if wanted.

BTW, having everyone inherit from a base class that you add to in the future
is *NOT* generally a good practice - it makes for very brittle class
hierarchies, and often tempts developers to build severely overloaded base

PaulS :)

View raw message