Hi Sébastien,
Le 14/07/2011 09:44, Ted Dunning a écrit :
Because when the interface changes, an abstract class can add default
implementations (even if the implementations only throw unimplemented
operation exceptions).
That means that code that has used the abstract class won't have to break.
If you change an interface, the implementing code inevitably breaks.
To explain a little further what Ted means above, [math] tries to keep
compatibility between releases, except for major releases. We have
already been hit by interfaces problems due to this management rule: we
did a wrong design on interfaces, but could not fix our errors without
breaking compatibilities. With abstract classes, when the error was
simply something forgotten, it is easy to add without breaking existing
user implementation that extend this: they will inherit the added method
implementation when they are compiled against the new version of [math].
This does not mean interfaces are evil and should be avoided. There are
many places where interfaces are very well suited. One of the use of
interface we still promote is for user code that represent some problem
to be passed to a [math] algorithm. Examples are functions that are
passed to root solvers or integrators (interface UnivariateRealFunction
and similar), ordinary differential equations (interface
FirstOrederDifferentialEquation), visitors for matrices elements
(interface RealMatrixChangingVisitor and similar) ... In these cases, we
really have nothing we can implement at [math] level and more
importantly the user object will implement our [math] interface, but
they still have the freedom to extend some other user base class at the
same time, to suit user needs. forcing user to extend a [math] abstract
class in this case would really be cumbersome for users.
So you see there is no silver bullet, sometimes we use interface,
sometimes we don't. We used a lot more interfaces before and are
changing our minds on some use cases.
best regards,
Luc
2011/7/13 Sébastien Brisard<sebastien.bris...@m4x.org>
We would then have had an empty abstract class. So why not an interface?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
