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

[Jason Hunter]

> 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,... .)

We started with interfaces.  Then we switched over to concrete classes
and for the most part I'm happy with that decision.  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.  With concrete classes there's no
such complications.

> hybrid implements-JDOM-but-extends-DOM objects, 
> or a set of implements-DOM-and-JDOM objects. 

Ugh, I see no reason to mix DOM and JDOM like that.  Use one or the
other.  If you have a tool that you want to manipulate both, write a
small abstraction layer, but don't make the APIs look like each other.

> 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.

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.

-jh-