[jdom-interest] Re: Interfaces? (was: W3 DOM support)

[Joe Bowbeer]

I agree with Louis that "articulating" the JDOM object structure into
Interface, AbstractClass, and DefaultImplementaion could open more
doors, but I'm not convinced that those doors need opening right now.

I do disagree with Jason on one point: I don't believe that adding
interfaces means having to use factories.  Internally yes (and that may
be what is meant), but I think the user can avoid factories by sticking
to the default implementations.  For example, IElement would be the
interface and Element would be the default implementation.

And I'm not a big fan of subclassing.  I'd rather delegate.  To my mind,

subclassing is a fragile, often requiring intimate knowledge of the
source code and leaving oneself vulnerable to future revisions of the
base classes.

For my uses of JDOM, though, leaving out interfaces seems good enough
for now.  Extracting interfaces could be a 2.0 thing, no?
--
Joe Bowbeer


Louis Tribble wrote:
> > Is there a reason that the public API classes
> > (Document, Element, Comment, and company)
> > are classes rather than interfaces? (The classes
> > would become, for example, DefaultDocument,
> > DefaultElement,... .)

Jason Hunter wrote:
> It makes for a cleaner, easier-to-understand system
> and makes creating documents MUCH easier.
> With interfaces you have to use factories to create
> everything, and you get into issues when moving
> elements created with one factory into documents
> created with another.

Louis Tribble wrote:
> > My instinct is that interfaces are also better for
> > alternate implementations of the "pure" API. The
> > lazy Builder on the wish list, or an implementation
> > that supports persistence and/or transactional
> > updates, for example.

Jason Hunter wrote:
> Subclassing can handle those tasks.  You do have
> to do more work than with the classic JDOM classes,
> but only as much work as you'd have to do using
> interfaces, and with interfaces you'd have to do that
> work for everything.
>
> Heck, you can subclass Element and reimplement
> every method if you want, treating it like an interface.
> Well, except for the final methods, and really our
> ability to declare finals (for equals() for example) is
> another advantage of concrete classes.