commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] RealLinearOperator and AbstractRealMatrix
Date Thu, 14 Jul 2011 08:24:16 GMT
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.brisard@m4x.org>
>
>> We would then have had an empty abstract class. So why not an interface?
>


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message