Can my project survive without Object Orientation?

Question

I am writing a small MATLAB package which will solve a certain class numerical problems. There are 3 stages of the algorithm and the user has 5 choices for each stage. I have implemented the entire problem using $\approx 20$ functions and 3 switch cases (one for each algorithm stage). It works fine but I am considering making it do more things (more than 5 choices and one more stage) and also make a Python port (some people are interested).

I was wondering if I should convert to a OOP framework (which I am not good at, at all) or whether I should stick with the procedural framework I have (which I am good at). I have made sure in my procedural code that no function does two things and there is minimal overlap (2 code-segments almost never do the same thing).

Please migrate this to SO if you feel it is more fitting in their domain.

Answer 1

There is no need to convert to a OOP framework, in order to benefit from object orientation where it helps. Note that the number of functions is less of an indicator than code duplication within and between these functions, or the length of these functions. (A function with more than 100 lines of code would be a typical indication for "improvement potential".)

If you should be unable to spot the parts where object orientation would help, converting to an OOP framework would not be the best first step. Rather ask somebody familiar with object orientation what could be simplified or improved, and then try to understand why it is a simplification or improvement.

If you want to use a framework like deal.II or PETSc, use them if the functionality they offer is useful for you, not because you think it will make your own code better or more maintainable. But you are already within the MATLAB framework, so it is unlikely that you want to change to a C++ OOP framework instead. (MATLAB offers full OOP support, as you probably know already.)

For the Python port, just do it based on your current knowledge for a start, and have a second start later after you learned enough to make it significantly better.

Answer 2

This question might be a good fit for Stack Overflow. I think it's also a good fit here because it's a common issue in computational science.

In terms of composing algorithms, a good example of a library that does this well is PETSc, if you can read C code. Object-oriented programming style may help with encapsulating data, but as a simple first step, you might just want to make each choice for a stage a function with a common interface. Then, for your algorithm, pass in a function for each stage as input and have the main algorithm call the function for each stage.

Answer 3

Not everything is well modeled by objects. Consider $1 + 1$, typically an OO system will treat the 1s as objects and the + as a method, 1.plus(1), but this does not correspond to our natural interpretation of $1+1$ as a binary infix function plus(1,1); it introduces an unnatural asymmetry between the first 1 as being the object for which the method plus is defined, and the second which is the argument to that method (this gives rise to kludges like __plus__ and __rplus__ in Python).

So don't feel that you need to force the square peg into the round hole, if you algorithm looks good in plain procedural fashion then keep it like that. If it needs to be included in an OO system you can always put an OO interface on your non-OO code. C++ coders do this every day (and even get paid for it).