Может ли мой проект выжить без объектной ориентации?

Я пишу небольшой пакет MATLAB, который решит числовые задачи определенного класса. Есть 3 этапа алгоритма, и пользователь имеет 5 вариантов для каждого этапа. Я реализовал всю проблему, используя$\approx 20$функции и 3 случая переключения (по одному на каждый этап алгоритма). Он работает нормально, но я рассматриваю возможность сделать больше вещей (более 5 вариантов и еще один этап), а также сделать порт Python (некоторые люди заинтересованы).

Мне было интересно, стоит ли мне переходить на OOP-фреймворк (что у меня вообще плохо получается) или мне следует придерживаться процедурной структуры, которая у меня есть (что я хорошо умею). В своем процедурном коде я убедился, что ни одна функция не выполняет две функции и имеет минимальное перекрытие (2 сегмента кода почти никогда не делают одно и то же).

Пожалуйста, перенесите это в SO, если вы чувствуете, что это более уместно в их области.

Нет необходимости переходить на OOP-фреймворк, чтобы извлечь выгоду из ориентации объекта, где это помогает. Обратите внимание, что количество функций является меньшим показателем, чем дублирование кода внутри и между этими функциями или длина этих функций. (Функция с более чем 100 строками кода будет типичным показателем «потенциала улучшения».)

Если вы не сможете определить части, в которых может помочь ориентация объекта, преобразование в структуру ООП не будет лучшим первым шагом. Скорее спросите кого-нибудь, знакомого с ориентацией объекта, что можно упростить или улучшить, а затем попытайтесь понять, почему это упрощение или улучшение.

Если вы хотите использовать такие платформы, как deal.II или PETSc, используйте их, если предлагаемая ими функциональность полезна для вас, а не потому, что вы думаете, что она сделает ваш собственный код лучше или удобнее в обслуживании. Но вы уже находитесь в среде MATLAB, поэтому вряд ли вы захотите перейти на среду C ++ OOP. (MATLAB предлагает полную поддержку ООП, как вы, наверное, уже знаете.)

Для порта Python, просто сделайте это, основываясь на ваших текущих знаниях для начала, и сделайте второй старт позже, после того, как вы выучите достаточно, чтобы сделать его значительно лучше.

Этот вопрос может подойти для переполнения стека. Я думаю, что это также хорошо подходит здесь, потому что это общая проблема в вычислительной науке.

С точки зрения составления алгоритмов, хорошим примером библиотеки, которая делает это хорошо, является PETSc, если вы можете читать C-код. Стиль объектно-ориентированного программирования может помочь в инкапсуляции данных, но в качестве простого первого шага вы можете просто захотеть сделать каждый выбор для этапа функцией с общим интерфейсом. Затем для вашего алгоритма передайте функцию для каждого этапа в качестве входных данных и попросите главный алгоритм вызвать функцию для каждого этапа.

Не все хорошо моделируется объектами. Рассматривать$1 + 1$, как правило, ОО-система будет рассматривать 1s как объекты, а +как метод 1.plus(1), но это не соответствует нашей естественной интерпретации$1+1$как двоичная инфиксная функция plus(1,1); он вводит неестественную асимметрию между первым 1как объектом, для которого определен метод plus, и вторым, который является аргументом этого метода (это приводит к появлению кладж, как __plus__и __rplus__в Python).

Так что не думайте, что вам нужно втиснуть квадратный колышек в круглое отверстие, если ваш алгоритм выглядит хорошо в простой процедурной манере, тогда сохраняйте это так. Если он должен быть включен в ОО-систему, вы всегда можете добавить ОО-интерфейс к своему не-ОО-коду. C ++ кодеры делают это каждый день (и даже получают за это плату).