[jdom-interest] Re: jdom comparison with dom4j

[James Strachan]

From: "Dennis Sosnoski" <dms at sosnoski.com>
> The dom4j approach of
> using multiple layers of interfaces with both abstract and (default)
concrete
> implementations, factories, etc. gives a lot of flexibility but also can
make
> for some confusion ("let's see, there's probably a method to do X, but is
it an
> Element method, a Node method, or...?").

Agreed. One of the main downsides of using polymorphism and inheritence is
walking up the inheritence tree to find all the methods that are available.

Most Java IDEs these days seem to be capable of doing this for us, for
example typing the following into an IDEs editor

    Element element = parent.addElement( "foo" );
    element.

when the last dot is entered after "element", the editor will often make a
popup appear with all the methods available on the element variable for us
to choose from.

The problem tends to be javadoc. Its a shame the default output isn't to
show all the methods available for a given class or interface in the 'Method
Summary' section, with an option to filter the methods available into groups
of which interface/class they come from.

Then a user looking up (say) an Attribute interface wouldn't need to care
where the 'getParent()' method was defined and inherited from or have to
visually walk up the inheritence tree to find it - they'd just see that its
available on Atribute. Then hopefully using inheritence and polymorphism
wouldn't adversely affect a javadoc surfer.

Maybe this is a good use case for a new javadoc doclet...

James



_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com