Чи може мій проект вижити без орієнтації на об'єкт?

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

Мені було цікаво, чи слід переходити на рамки ООП (в чому я взагалі не хороший), чи слід дотримуватися процедурної бази, яка в мене є (в чому я хороший). Я переконався в своєму процедурному кодексі, що жодна функція не робить двох речей і є мінімальне перекриття (2 кодові сегменти майже ніколи не роблять одне і те ж).

Будь ласка, перенесіть це на SO, якщо ви вважаєте, що це більше відповідає їхній області.

Немає необхідності перетворюватись на рамки OOP, щоб отримати користь від орієнтації на об'єкти, де це допомагає. Зауважте, що кількість функцій є меншим показником, ніж дублювання коду всередині цих функцій і між ними, або тривалість цих функцій. (Функція з більш ніж 100 рядками коду була б типовою ознакою для "потенціалу поліпшення".)

Якщо вам не вдасться помітити частини, де допоможе орієнтація об'єкта, перетворення в рамки OOP було б не найкращим першим кроком. Скоріше запитайте когось, знайомого з орієнтацією на об'єкт, що можна спростити або вдосконалити, а потім спробуйте зрозуміти, чому це спрощення чи вдосконалення.

Якщо ви хочете використовувати таку структуру, як deal.II або PETSc, використовуйте їх, якщо функціонал, який вони пропонують, є корисним для вас, а не тому, що ви думаєте, що це зробить ваш власний код кращим або більш ретельним. Але ви вже перебуваєте в рамках MATLAB, тому навряд чи ви хочете замість цього перейти на рамки C ++ OOP. (MATLAB пропонує повну підтримку OOP, як ви, напевно, вже знаєте.)

Що стосується порту Python, просто зробіть це на основі ваших поточних знань для початку, а другий запуск пізніше після того, як ви навчились достатньо, щоб зробити його значно кращим.

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

З точки зору складання алгоритмів, хорошим прикладом бібліотеки, яка робить це добре, є PETSc, якщо ви можете прочитати код C. Об'єктно-орієнтований стиль програмування може допомогти з інкапсуляцією даних, але, як перший простий крок, ви можете просто зробити кожен вибір для етапу функцією із загальним інтерфейсом. Потім, для вашого алгоритму, передайте функцію для кожного етапу як вхідну і майте головний алгоритм викликати функцію для кожного етапу.

Не все добре моделюється об’єктами. Розглянемо$1 + 1$, як правило, система ОО трактує 1s як об'єкти та +метод як метод 1.plus(1), але це не відповідає нашій природній інтерпретації$1+1$як функція бінарної інфіксації plus(1,1); вона вводить неприродну асиметрію між першим 1як об'єктом, для якого визначений метод plus, і другим, що є аргументом цього методу (це породжує хижі, як __plus__і __rplus__в Python).

Тому не відчувайте, що вам потрібно примусити квадратний кілочок до круглого отвору, якщо алгоритм виглядає добре в процедурному порядку, тоді зберігайте це так. Якщо його потрібно включити в систему OO, ви завжди можете поставити інтерфейс OO на свій код, який не є OO. C ++ кодери роблять це щодня (і навіть отримують за це плату).