Hi folks,
the problem pointed out was not removing interfaces but to tell people
there is a behaviour in abstract
base classes that is the minimal expected behaviour of the classes
implementing the interface (tell me
if I'm wrong).
So one could just remove the interface and replace it with the abstract
base class breaking almost everything. The suggestion Dan made is suitable
to communicate the benefit of using the abstract base class but a bit
weird. Using language/code features to communicate design needs literally?
Having this kind of pattern in a lot of interfaces clutters your code with
the meaningless method implementations. Perhaps then using a "single"
method that points this out would be better? An method signature that is
shared in all interfaces using this pattern? So that implementing classes
would have only to implement a single notificatory method. e.g.
void implementOnlyDirectlyIfDefaultBaseClassIsNotSuited();
or. void notSuitedForDirectImplementation();
perhaps putting this "communicative behaviour" into a separate interface
and extending this would be another possibility.
e.g.
interface HasSuitableDefaultImplementation {
void notSuitedForDirectImplementation();
}
interface World extends HasSuitableDefaultImplementation {
...world interface methods
}
interface Given extends HasSuitableDefaultImplementation {
...given interface methods
}
To find the base class is a task I expect any developer to be able to do.
The question is should we prefer composition to inheritance? Most times
composition or delegation is better suited for solving problems as there
is no muliple inheritance (or injection which I like much more) in Java.
But both interfaces and abstract base classes may be used in compositional
approaches whereas enforced abstract base classes have problems when there
is an existing class hierarchy.
So keeping the interface, having it communicate that there is an abstract
base class that contains the default behaviour would be fine. Another way
may be to embed the abstract base class as a default implementation in the
interface.
When removing the interface you bind all implementations to the abstract
base class even if they do not need the behaviour and _data_ of this class.
Perhaps one could make the World etc interfaces package protected forcing
people to place public interfaces which extend these interfaces in the
jbehave packages
This is no point about the usefulnes of the public interface API of
JBehave. I also think they fit quite well.
But I think there is no need to force people using the base classes.
Anyone who deals with JBehave reads at least something in the source code
or on the website. So pointing out the usefulness of the base class
implementation there would (imho) be enough. Developers should be sensible
enough (sweet dream?) to deal with a framework. It is just about "forcing"
them to think about the things they do.
Michael, lengthy as ever :)
P.S: The posting of Dan was not about evolving interfaces, was it?
Evolving APIs and interfaces are another point.
---------------------------------------------------------------------
To unsubscribe from this list please visit:
http://xircles.codehaus.org/manage_email
