Yep, I agree.
The one word counterexample that made it for me was GivenScenario. How
do you do that with abstract superclasses? :)
Just thought I'd float the idea.
I think it's different in Joe's world because the point of Hamcrest is
for you to derive your own matchers, so you would expect to find many
custom matchers.
In our world, the classes we provide should do most of the work, so a
change to the interfaces carries much less impact.
So, for the record, I don't plan on changing them any time soon.
Thanks,
Dan
Mauro Talevi wrote:
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
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
