Hi Dan,
Dan North wrote:
Hi folks.
I've been following an interesting discussion about evolving APIs, and
there's something I'd like to do for jbehave 1.1.0. Technically it
should be jbehave 2.0.0 by my own definitions, in that it will break
existing client code, so I want to get it out there as quickly as
possible to minimise the impact.
It turns out evolving an interface in a statically-typed language is a
non-backwards compatible action. What I mean is, if I add or change a
method, then any clients implementing that interface will break, which
is obviously a Bad Thing.
There's a nice pattern to manage this that looks like this:
/**
* javadoc describing what the interface does and saying
* to evolve the [EMAIL PROTECTED] BaseEvolvableThing}
*/
*interface EvolvableThing* {
void doSomething();
/** this is for people who don't read javadocs */
void *__dont_implement_this_extend_BaseEvolvableThing_instead*();
}
public *abstract class BaseEvolvableThing implements EvolvableThing* {
public abstract void doSomething(); // or have a default implementation
public void __dont_implement_this_extend_BaseEvolvableThing_instead(){};
}
which I'd like to sneak into the codebase for Story, Scenario, Given,
Event, Outcome, Step, Behaviour and World (plus any others I've
forgotten) before people start implementing them.
So I need to know:
a) are you implementing any of these interfaces directly, and
b) how painful will it be to change to extend an abstract base class?
Thanks,
Dan
ps. Thanks to Joe Walnes & friends for the pointers.
I've seen this pattern from Joe et al. But I still struggle to see the benefit
of it.
Firstly - an interface should not be "unimplementable" - ever. I the designer does not want it to
be implementable, simply remove it and leave only the abstract class.
Secondly, what does it benefit us to have *only* the abstract class.
The interface should express the functionality and the abstract class be
helpful in it's implementation.
Thirdly, I personally don't like the attitude which I find a bit patronising, about the "people who
don't read javadoc".
My 3c :-)
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
