Thanks Luc and Ted,
that's clear enough.
I'm looking forward to keep on working on linear operators and iterative
solvers when I'm back.
Sebastien
Le 14/07/11 10:24, Luc Maisonobe a écrit :
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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
