Many algorithms used in scientific computing have a different inherent structure than algorithms commonly considered in less math-intensive forms of software engineering. In particular, individual mathematical algorithms tend to be highly complex, often involving hundreds or thousands of lines of code, yet nonetheless involve no state (i.e. are not acting upon a complex data structure) and can often be boiled down -- in terms of programmatic interface -- to a single function acting on an array (or two).
This suggests that a function, and not a class, is the natural interface to most algorithms encountered in scientific computing. Yet this argument offers little insight regarding how the implementation of complex, multi-part algorithms should be handled.
While the traditional approach has been to simply have one function that calls a number of other functions, passing the relevant arguments along the way, OOP offers a different approach, wherein algorithms can be encapsulated as classes. For clarity, by encapsulating an algorithm in a class, I mean creating a class wherein the algorithm inputs are entered into the class constructor, and then a public method is called to actually invoke the algorithm. Such an implementation of multigrid in C++ psuedocode might look like:
class multigrid {
private:
x_, b_
[grid structure]
restrict(...)
interpolate(...)
relax(...)
public:
multigrid(x,b) : x_(x), b_(b) { }
run()
}
multigrid::run() {
[call restrict, interpolate, relax, etc.]
}
My question is then as follows: what are the benefits and drawbacks of this kind of practice as compared to a more traditional approach without classes? Are there issues of extensibility or maintainability? To be clear, I am not intending to solicit opinion, but rather to better understand the downstream effects (i.e. those that might not arise until a codebase becomes quite large) of adopting such a coding practice.