commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject [Math] What's the problem with interfaces?
Date Wed, 30 Mar 2011 00:15:32 GMT

> We have been talking about moving away from interfaces as the
> preferred way to support people plugging in alternative
> implementations because they have in several places gotten "behind"
> due to the fact that adding anything to them breaks compatibility.
> We should probably continue that discussion in a different thread.

[This is the different thread.]

>From comments that were posted to the other thread, I gather the main trend
that, because some interfaces needed an upgrade, the "interface" design tool
is becoming "evil". Did I get this right?

I guess that you refer to "RandomData" and "RandomDataImpl". This is indeed
the typical example of abusing the "interface" tool. When only one
implementation is meaningful, an "interface" need not be defined.

The "interface" is not the way (preferred or not) to support alternative
implementations. As was already said, this is done with (abstract or not)
classes which an alternative implementation can inherit from.
Rather, the (Java) "interface" is supposed to represent the abstraction
(from the "real" world object) of everything that is needed to interact with
that object (i.e. its interface). It makes it possible to treat different
objects on a equal footing (from the caller's point-of-view).
But you all know that...

So what's the problem? Is it the binary compatibility, again? This is a
configuration management issue. When the compatibility is broken, you change
the major version number and/or the base package name. That was settled, or
It would be a pity to sacrifice a tool aimed at improving the design because
of such considerations as keeping backward compatibility with versions that
nobody here is going to support.
If some user is happy with version "M.m", he can use it forever. If he wants
to use a newer version "N.n", he should not expect it to be compatible. It
does not have to be! Non-compatible modifications are not performed out of
some urge for change but stem from the desire to get a better product, bits
by bits.

Yes, it's not easy to get the interfaces right; so what? If you find that
you can improve the design, you do it and bump the major verion number.
As someone pointed out, it's not as if we'll run out of numbers.

Part of the real problem (as shown by the amazing amount of done and undone
work for 2.2) is that you (collectively) want to do too many things at the
same time (lots of changes *and* few releases). To be clear, the problem is
not the "lots of changes" part (which you would like to "solve" by vetoing
future compatibility-breaking improvements). Note that the following is not
a criticism of CM (which has many features etc.) but some of the code that
I've seen (in the parts which I've more closely looked at) do not make me
think that it is mature enough that one can say "That's it!" and stick with
the design forever.
Again, all this (e.g. removing duplicate code and refactoring the design)
can be considered unimportant and swept under the carpet but IMO *any*
cleanup is good as it will contribute to the overall robustness and
Half-baked design will continue to itch.

Best regards,

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message