arosen at novell.com
Fri Feb 27 22:45:36 PST 2004
I vote for class or abstract class. Here's part of my notes from one of
the presentations at EclipseCon a few weeks ago.
"He advised that you shouldn't create interfaces that you expect users
to implement - use abstract classes instead, for forward compatibility.
You can't add new methods to an interface that a user is implementing -
you have to use the hacky "MyInterface2 extends MyInterface" workaround.
He said that wherever they've had interfaces that users are expected to
implement, they've regretted it. (Having interfaces that the user is not
expected to implement, to hide your implementation classes, is fine.) He
had a big bushy programmer's beard, so he must know what he's talking
>>> Jason Hunter <jhunter at xquery.com> 2/27/2004 9:30:50 PM >>>
FYI, I just made an interesting commit. People not on the commits list
might want to take a look:
This change also made me think, should JDOMFactory really be an
interface, a class, or an abstract class? The problem with an
is that if we add methods after 1.0 it breaks everyone implementing the
interface. With a class or abstract class, we can add w/o breakage so
long as the new methods can have a standard implementation.
To control your jdom-interest membership:
More information about the jdom-interest