Hi. I wrote the original version of Hamcrest, although Joe Walnes
added this wierd method to the base class.
The reason is because of a peculiarity of the Java language. As a
commenter below said, defining Matcher as a base class would make it
easier to extend the library without breaking clients. Adding a method
to an interface stops any implementing classes in client code from
compiling, but new concrete methods can be added to an abstract base
class without breaking subclasses.
However, there are features of Java that only work with interfaces, in
particular java.lang.reflect.Proxy.
Therefore, we defined the Matcher interface so that people could write
dynamic implementations of Matcher. And we provided the base class for
people to extend in their own code so that their code would not break
as we added more methods to the interface.
We have since added the describeMismatch method to the Matcher
interface and client code inherited a default implementation without
breaking. We also provided additional base classes that make it easier
to implement describeMismatch without duplicating logic.
So, this is an example of why you can't blindly follow some generic
"best practice" when it comes to design. You have to understand the
tools you're using and make engineering trade-offs within that
context.
EDIT: separating the interface from the base class also helps one cope
with the fragile base class problem:
If you add methods to an interface that is implemented by an abstract
base class, you may end up with duplicated logic either in the base
class or in subclasses when they are changed to implement the new
method. You cannot change the base class to remove that duplicated
logic if doing so changes the API provided to subclasses, because that
will break all subclasses -- not a big problem if the interface and
implementations are all in the same codebase but bad news if you're a
library author.
If the interface is separate from the abstract base class -- that is,
if you distinguish between users of the type and implementers of the
type -- when you add methods to the interface you can add a default
implementation to the base class that will not break existing
subclasses and introduce a new base class that provides a better
partial implementation for new subclasses. When someone comes to
change existing subclasses to implement the method in a better way,
then can choose to use the new base class to reduce duplicated logic
if it makes sense to do so.
If the interface and base class are the same type (as some have
suggested in this thread), and you then want to introduce multiple
base classes in this way, you're stuck. You can't introduce a new
supertype to act as the interface, because that will break client
code. You can't move the partial implementation down the type
hierarchy into a new abstract base class, because that will break
existing subclasses.
This applies as much to traits as Java-style interfaces and classes or
C++ multiple inheritance.