Многие алгоритмы, используемые в научных вычислениях, имеют внутреннюю структуру, отличную от алгоритмов, обычно рассматриваемых в менее интенсивных математических формах разработки программного обеспечения. В частности, отдельные математические алгоритмы, как правило, очень сложны, часто включают сотни или тысячи строк кода, но, тем не менее, не содержат состояния (то есть не действуют на сложную структуру данных) и могут часто сводиться к нулю - с точки зрения программного интерфейс - к единственной функции, действующей на массив (или два).
Это говорит о том, что функция, а не класс, является естественным интерфейсом для большинства алгоритмов, встречающихся в научных вычислениях. Тем не менее, этот аргумент дает мало понимания того, как следует реализовывать сложные алгоритмы, состоящие из нескольких частей.
Хотя традиционный подход состоял в том, чтобы просто иметь одну функцию, которая вызывает ряд других функций, передавая соответствующие аргументы по пути, ООП предлагает другой подход, в котором алгоритмы могут быть инкапсулированы как классы. Для ясности, под инкапсуляцией алгоритма в классе я имею в виду создание класса, в котором входные данные алгоритма вводятся в конструктор класса, а затем вызывается открытый метод для фактического вызова алгоритма. Такая реализация multigrid в C ++ psuedocode может выглядеть так:
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.]
}
Мой вопрос заключается в следующем: каковы преимущества и недостатки такой практики по сравнению с более традиционным подходом без занятий? Существуют ли проблемы расширяемости или ремонтопригодности? Чтобы быть ясным, я не собираюсь запрашивать мнение, а скорее лучше понять последующие эффекты (то есть те, которые могут не возникнуть, пока кодовая база не станет достаточно большой) принятия такой практики кодирования.