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

[Patrick Dowler]

On Wed, 06 Dec 2000, Jason Hunter wrote:
> I also remain open minded about some interface use.  But here's how I
> see it.  With the interface design (the one that doesn't depend on
> factories for every object creation) the only advantage interfaces offer
> that I can't replicate with base classes is support for implementing the
> JDOM API in a class that wasn't designed foremost as a JDOM class, and
> that sounds like a questionable design.  The price of that interface
> architecture is we can no longer declare final methods like equals(). 
> Also, we'll have this IElement interface that no one uses because they
> say new Element(), and thus an alternate implementation couldn't really
> just "plug-in" anyway unless people took care to say IElement and
> IAttribute.  If you see other advantages, speak up.

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. Obviously, they are assuming that the methods perform some
specified task in a standard way. It is just a declaration of the presence of
methods. What's more, it is a way for a method to declare that it only does
certain things, ie

public interface MyInterface
{
   public void doSomething();
}

then elsewhere:

       public void doit( MyInterface obj) { ... }

This is a declaration that "doit" only calls the doSomething() method
on your object. You object can do all sorts of things and they are hidden
from doSomething(). 
 
> Now, the other interface model (where factories are used for all object
> creation) has its own set of problems that people who've used DOM are
> familiar with.

Using interfaces doesn't mean using factories. Just the decarative use outlined
above is very nice for people writing code that uses the public API - which is
most code - in a way that is somewhat insulated from other code. Just grouping
some methods under an interface signature means that it is very easy to
discover the impact of code changes, for example. If an object implements
MyInterface and OtherInterface (and they are functionally separate sections of
code) and I change the  doSomething() method, it is not going to effect any 
code that operates on OtherInterface objects. I could also split said object in two
later on with no effect on code that uses either interface. 

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);

or something like that. It otherwise lets one keep the method signatures very clean
and consistent.

***

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'm not so much talking about permission right now for this particular project,
but without interfaces, others are forced to actually use that name rather than
just bundle jdom-interfaces.jar with their implementation. Thus, making an
alternate implementation is pretty hard without interfaces or blanket permission
to implement classes in org.jdom (at least), if not all the jdom sub-packages.
As a result, although the project is called FooXML, it still has to use the
packaging layout of JDOM.

Is this a problem? I take it that the W3C has  given explicit blanket permission
for people to implement org.w3c.<stuff>...

-- 

Patrick Dowler
Canadian Astronomy Data Centre