commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <>
Subject Re: [Math] What's the problem with interfaces?
Date Wed, 30 Mar 2011 17:05:42 GMT
We are mixing two things in this thread - how much we care about
backward compatibility and how and when to use interfaces.

I think we need to settle both topics.  I have stated my view, which
is really just to standard Commons policy, on the backward
compatibility issue.  Based on many years experience using,
developing and maintaining libraries here and elsewhere, I agree
with others who have stated that constant incompatible change makes
a library almost worthless for use across a wide range of
applications.  Something just used inside one application or
relatively small development group can be constantly refactored and
productively used; but broadly reusable components need to have
stable APIs.  Incompatible changes have to be well-documented and
introduced in major releases that are relatively few and far
between.  That is essentially how we have operated in Commons for
10+ years now and it is the reason that some suggest that when we do
a major API refactoring of a component we change the package name
and even the component name.

I don't buy the argument that we really *need* to keep making
incompatible API changes in [math] because there are features or
bugs that can't be added in compatible ways.  I have seen only a
tiny handful of these - just one in 2.2.  Luc mentions SVD as a
frustrating problem for us.  The bugs have nothing to do with the
API definition, unless I am missing something basic.  We have
numerical problems.  We need to solve them.  Gilles is right that we
have limited resources.  I would much rather that these resources be
focused on solving the numerical and algorithmic problems involved
in delivering robust and stable mathematical software than endless
arguments about how to refactor the API.  As a user, I would be much
happier with a stable API with a few warts that provides
well-documented, well-tested (because lots of users are using the
*same* core impl) mathematics than a beautiful but unstable API with
buggy implementation code.

Regarding interfaces, I think we are starting to focus on the right
question.  I think we agree that use of interfaces just to separate
interface from implementation in support of the strategy pattern is,
let's just say "deprecated."  When we started [math] back in 2003,
that was not considered bad design.  We went overboard with it,
though, and ran into the problems we have been discussing on this
thread around extensibility.  Most of the bad designs came from my
contributions, so I have to apologize for putting us into this position.

To allow multiple implementations of a fully defined interface, we
seem to have learned in Commons that abstract classes work better. 
I am fine with that principle and will volunteer to start first
suggesting and discussing changes individually and then making
them.  I already started this with RandomData/RandomDataImpl.  We
can continue discussion on that thread about whether we even need an
abstract class in that case.

Other use for interfaces are to
 a) designate behaviors for implementation units that can be
"plugged in" to algorithms (where the interface defines only some of
the behaviors of the class - as in the multiple inheritance
example).  An example of this is the RandomGenerator interface,
which encapsulates the behavior of a low-level source of random data.
 b) encapsulate abstract data types, e.g. Field.

I think we need to keep at least these interfaces, but we should
think long and hard about exactly what they should contain.  Here
again, I think we need to look at each example individually. 
Examples like RealMatrix could be argued to be good "b)" examples or
restrictive handcuffs that should be eliminated.  I think we need to
be very careful with these decisions so that we can aim to really
stabilize the API in 3.0.  I honestly do not think that is an
unrealistic expectation.


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

View raw message