ПП для моделювання та моделювання

Я збираюся розпочати проект моделювання / моделювання. Я вже знаю, що OOP використовується для подібних проектів. Однак вивчення Haskell змусило мене розглянути можливість використання парадигми FP для моделювання системи компонентів. Дозвольте мені детальніше:

Скажімо, у мене є компонент типу A, який характеризується набором даних (такий параметр, як температура чи тиск, PDE та деякі граничні умови тощо) та компонент типу B, який характеризується різним набором даних (різними або той же параметр, різні PDE та граничні умови). Припустимо також, що функції / методи, які будуть застосовані до кожного компонента, однакові (наприклад, метод Галеркіна). Змінний стан об'єкта буде використовуватися для непостійних параметрів.

Якби я використовував підхід OOP, я створив би два об'єкти, які інкапсулювали б дані кожного типу, методи вирішення PDE (спадкування буде використано тут для повторного використання коду) та рішення для PDE.

З іншого боку, якби я використовував FP-підхід, кожен компонент був би розбитий на частини даних та функції, які діятимуть на дані, щоб отримати рішення для PDE. Нестабільні параметри передаються як функції чогось іншого (наприклад, час) або виражаються якоюсь мінливістю (емуляція змінності тощо). Цей підхід мені здається більш простим, якщо припустити, що лінійні операції над даними були б тривіальними.

На закінчення, чи було б реалізація підходу FP насправді простішою та простішою в управлінні (додати інший тип компонента чи новий метод вирішення pde) порівняно з OOP?

Я походжу з C ++ / Fortran, плюс я не професійний програміст, тому виправте мене з усього, що я помилився.

Добре запитання, я розмірковував у подібних напрямках. Історично парадигма OO виникла з необхідності комп'ютерного моделювання - див. Історію Simula - і незважаючи на ранні мови OO, такі як Smalltalk, які складаються людьми, які знали, що вони роблять (наприклад, Алан Кей), OO зараз, мабуть, надмірно використовується і приносить занадто багато випадкових складностей .

Як правило, програми в стилі FP будуть коротшими, простішими для тестування та легшими для зміни, ніж програми OO. Як Роб Харроп висловився у своїй розмові, чи функціонує майбутнє? , ви ніколи не можете отримати простіші за функції та дані; вони складаються нескінченно, щоб будувати будь-які абстракції. Отож, один із способів відповісти на ваше запитання (чи я його просто перевстановлюю? :) - запитати, як виглядає функція найвищого рівня та вхідні дані вищого рівня -> вихідні дані? Тоді ви можете почати розбивати ці "альфа" функції та типи даних на наступний рівень абстракцій та повторювати за необхідності.

Ще одна точка зору (не зовсім відповіді) на ваше запитання - це поглянути на цю тему (відмова, я її почав) на StackOverflow, деякі відповіді дуже цікаві: /programming/3431654/how-does- функціональне програмування - застосувати до моделювання

Моя власна думка на даний момент полягає в тому, що якщо ви не моделюєте ситуацію, коли дійсно існують дискретні об'єкти, які взаємодіють лише певними способами (наприклад, модель комп’ютерної мережі) - і таким чином безпосередньо відображати можливості чистого повідомлення, мова прохідної парадигми OO - простіше перейти на FP. Зауважте, що навіть у спільноті програмування ігор - де симуляції є дуже поширеними та вимоги до продуктивності є першорядними - досвідчені розробники відходять від OO-парадигми та / або використовують більше FP, наприклад дивіться цю дискусію HN або коментарі Джона Кармака щодо FP

ІМХО майже на кожне завдання розумної складності на питання "це стиль FP або стиль OOP, кращий вибір" не можна відповісти об'єктивно. Зазвичай у такій ситуації питання не є "ні FP, ні OOP", а як поєднати найкращі частини обох парадигм для вирішення вашої проблеми.

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

З іншого боку, PDE - це рівняння функцій, і рішення може знову функціонувати. Тож використання функціонального підходу для цього типу "компонентів" може здатися природним. Ці функції можуть мати параметри матриці, показуючи один приклад того, як поєднувати OOP і FP. Іншим прикладом може бути реалізація класу матриць, який використовує функціональні інструменти для відображення певної операції на кожен елемент вашої матриці. Тож і тут не найкращі результати приносять не "OOP проти FP", а "OOP у поєднанні з FP".