Mailing-List: contact commons-dev-help@jakarta.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Received-SPF: pass (hermes.apache.org: local policy)
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [digester] initial code for Digester2.0
Date: Wed, 2 Feb 2005 15:04:46 +1300
Message-ID: 
 <5F08B760C43F824AB2F061D146EC842502B6A0E3@WLG-EVS.contact-energy.co.nz>
Thread-Topic: [digester] initial code for Digester2.0
Thread-Index: AcUIx/5t3jp3DrXqQHORInzwo46A6AAAIMNQ
From: "Sharples, Colin" <Colin.sharples@contact-energy.co.nz>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>

> > - Why is Action an abstract class?
>=20
> So that we can later add new functionality to Action without breaking
> custom Action subclasses that users have written. As long as we can
> provide a suitable default implementation in the Action=20
> abstract class,
> everything runs smoothly.
>=20
> One example is the "bodySegment" callback that is now in Action. In
> Digester 1.x we could not have added this to Rule without breaking all
> custom Rule classes. But if digester2.0 had been released=20
> without it, we
> could have added it later with no source or binary compatibility
> problems.
>=20
> Of course because of Java's single-inheritance policy, it would be
> impossible for a class to extend both Action and some other class. But
> (a) this is extremely unlikely, and (b) using an "adapter" class works
> around this anyway if it absolutely has to be done.

I prefer interface + default abstract implementation, the way Swing =
provides e.g. Action* and AbstractAction. That way a class can still =
implement the interface even if it extends from something else, and use =
a delegate to implement the interface. You can still evolve the =
interface without breaking existing classes that extend the abstract =
class. Of course, there is nothing to force people to extend the =
abstract class, but you can make it clear in the doco for the interface =
that not to extend the abstract class is an explicit design choice that =
may have dire consequences.

* yes, the name Action is quite overused. Not that I can think of a =
better alternative... ;-)

Colin Sharples
IBM Advisory IT Specialist
Email: sharples@nz.ibm.com
Mobile: +64 21 402 085

---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org