Matrix Functions and Operations as Separate Class

[Suminda Dharmasena]

Having matrix operations in the matrix class is not a good design. 

E.G. There is a operation I want so I extend and add it. Later this is added to the matrix then there will issues of maintaining. 

Best is the operations and functions be separated. This means you can have user defined functions also.

[Suminda Dharmasena]

Breeze in Scalanlp uses this approach. This can be done here also thought the ability to register a function. Maybe a bit difficult in Java. 

[Vladimir Kostyukov]

Hi Suminda,

Thanks for mentioning the Scala libraries. I was discovering the API of those libraries before designing the la4j API.

 

My personal thoughts – there is no good or bad design. There is always a trade-off between tons of things. I was working quite a lot on API design in order to make it nice and clear for Java developers. Many people keep writing me regarding the API. They find it very simple and expressive. I think the same. There are couple of things that might be changed, but the general idea should be the same.

 

When it comes to OO design, the first question you have ask yourself is what I’m going to do with this object. Not what is object itself (what data inside). This is why la4j treats all the matrices the same via the Matrix interface. Thus, all the operations should be exposed there.

 

I was designing quite a lot in my carrier. Starting from compilers and finishing with math frameworks. But I was never treating any design like bad or good. There is no such metrics for abstract things. There is only two metrics regarding the design: (b) do you want to change it? (c) how easy it’s to make changes? You usually shouldn’t want to change it, but when you decided to do that it should be easy to do.

--
Thanks,

Vladimir Kostyukov