[jdom-interest] Announce: JDOMPlus a flexible XML framework for Java

[Jason Hunter]

> The biggest win for interface use is when someone writes a method that
> takes an Element and all they are after is enforcing a certain method
> signature. 

The ability to genericize is possible with concrete baseclasses.  Look
at java.lang.Object.

Interfaces in Java work around the multiple inheritance fiasco (where
you might extend from two classes with different implementations of the
same method and have to decide which to call) by saying interfaces have
no implementations and thus classes can implement multiple interfaces. 
So, as you point out, it lets you define functionality without
behavior.  In teaching Java I use the biological chart and ask people
where a Flyable class would go, for animals that can fly.  The answer of
course is that it's better to have a Flyable interface because not all
birds fly and not all mammals don't.

But do we need that in JDOM?  It's pretty clear an Element is an
Element, and if you want to have a custom Element you just subclass
Element instead of implementing an Element interface.  You lose only the
ability to make a random object into an Element.  :-)

Other than that, interfaces are basically abstract base classes.  And
abstract base classes are just concrete base classes except some methods
are left abstract because they have no reasonable standard
implementation.

> Basically, my argument is that interfaces are good for code that 
> uses the public API because people can write code that targets the 
> method signature they need and not the actual class they expect to 
> access.  This is the simplest use of interfaces, but also the most 
> powerful. The only adverse effect on code is that you have to say:
>
>       Element e = new ElementImpl(name);

That functionality is possible with a base class as well.  I expect
we'll have a builder that creates DeferredElement objects but people
will deal with them as Element objects.  People creating new Element
objects will be able to use new Element() to construct them because
they'll be compatible with DeferredElement.

And if people want to go for power and have a DatabaseBackedElement
subclassing Element where the whole tree is full of DBE's, that's still
possible too.  Have a builder that pulls data from a db and makes DBE's,
and since you're a power user you can create new elements as you want,
perhaps by passing a ResultSet to their constructor!  The standard user
is happy, but power users can extend Element for special Elements.  In
my opinion that makes more sense that implementing an Element interface
and making casual user's lives more difficult.

Define a good generally usable baseclass.  Allow creative
implementations as subclasses.

> On the subject of forking code and interfaces, there is one catch here
> that seems relevant. James' goal is for his fork to remain API 
> compatible with JDOM, which means that he needs to have classes named
> org.jdom.Element (etc). Is that an acceptable use of the word "jdom"?

I've been discussing this with Brett and others lately.  I'll announce
when we've come to a decision.

-jh-