[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: SAX2 RFD: Inheritance vs. Modification vs. Amalgamation

  • From: David Brownell <david-b@p...>
  • To: David Megginson <david@m...>
  • Date: Wed, 19 May 1999 14:09:44 -0700

interface inheritance vs implementation inheritanc
David Megginson wrote:
> 
> 1. Create a new interface, org.xml.sax.Parser2, that extends
>    org.xml.sax.Parser.
> 
>    PRO: - provides nice, two-way compatibility
>         - easy to write adapters for existing SAX 1.0 drivers.
>    CON: - subclassing always leads to crime (see the GOF book for
>           copious warnings).

Actually, strike that "con" -- this isn't subclassing, it's
instead "subtyping", since Parser is an interface not a class.

Inheriting interfaces can't cause the crimes you'd get by relying
on parent class implementation artifacts!

My preference is clearly for #1 ... it's the standard way to
evolve existing interfaces in Java and most other interface
oriented frameworks.


> 2. Add the methods to org.xml.sax.Parser, and require applications to
>    catch NoSuchMethodException when using the new methods, in case
>    they're concerned about what version they're dealing with.

As Miles recently noted, this depends on everyone upgrading to
conform to the Java 2 standard.  (I recall the internal discussions
at the time.  This was a conscious change in behavior; JDK 1.1 and 1.0
are now viewed as being in error.)  While desirable, it's not a
thing I see happening very quickly ... particularly in embedded
systems which conform to the JDK 1.1 behavior!!

The motivation for changing this depended on ease of evolution in
the specific case where interface definers have strong control
over all implementations of the interface ... which clearly is
not the case with SAX!!  (Note that this change removes one of
the incentives to use abstract base classes inappropriately!)


> 3. Create a separate interface org.xml.sax.ParserProps (or something
>    like that), and require SAX2 drivers to implement both interfaces.

The primary difference between this and #1 is that this defines another
interface, and I don't see a benefit to that.

- Dave

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev@i...
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo@i... the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo@i... the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa@i...)


PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.