Дизайн на «змішаних» мовах: об’єктно-орієнтований дизайн або функціональне програмування?

В останні кілька років мови, які я люблю використовувати, стають все більш "функціональними". Зараз я використовую мови, які є свого роду "гібридом": C #, F #, Scala. Мені подобається розробляти свої програми за допомогою класів, які відповідають об’єктам домену, і використовую функціональні функції, де це робить кодування простішим, зручнішим та безпечнішим (особливо при роботі з колекціями або при передачі функцій).

Однак два світи "стикаються", коли приходять до дизайнерських моделей. Конкретним прикладом, з яким я стикався нещодавно, є модель спостерігача. Я хочу, щоб виробник повідомляв про якийсь інший код ("споживачі / спостерігачі", наприклад, сховище БД, реєстратор тощо), коли елемент створюється або змінюється.

Я спочатку робив це "функціонально" так:

producer.foo(item => { updateItemInDb(item); insertLog(item) })
// calls the function passed as argument as an item is processed

Але мені зараз цікаво, чи варто використовувати більш "ОО" підхід:

interface IItemObserver {
  onNotify(Item)
}
class DBObserver : IItemObserver ...
class LogObserver: IItemObserver ...

producer.addObserver(new DBObserver)
producer.addObserver(new LogObserver)
producer.foo() //calls observer in a loop

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

EDIT: У моєму конкретному сценарії мені це не потрібно, але .. як би ви реалізували функціональне усунення та додавання "спостерігачів"? (Тобто, як би ви реалізували всі функції у шаблоні?) Просто передаючи нову функцію, наприклад?

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

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

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

Функціональна версія набагато коротша, простіша в обслуговуванні, легша для читання і, як правило, надзвичайно перевершена практично у будь-якому уявному відношенні.

Багато - хоча далеко не всі зразки - це компенсувати відсутність функцій OOP, наприклад, спостерігачів. Вони набагато краще моделюються функціонально.

Ваш "гуру ФП" частково правий; багато моделей OO - це хаки, щоб робити функціональні речі. (Його твердження, що це є причиною того, що декілька мов FP здається в кращому випадку сумнівним.) Шаблони спостерігачів та стратегій намагаються імітувати функції першого класу. Шаблон відвідувача - це хак для імітації відповідності шаблонів. Ви IItemObserverпросто маскуєтесь до функції. Здається, що він відрізняється від будь-якої іншої функції, яка бере предмет, нічого не купує.

Об'єкти - це лише один вид абстрагування даних. Цей документ допоможе пролити світло на цю тему. Об'єкти можуть бути корисними, але важливо визнати, що вони не підходять для всього. Дихотомії немає; просто питання вибору правильного інструменту для правильної роботи, а функціональне програмування ні в якому разі не вимагає відмови від об'єктів. Крім того, функціональне програмування - це більше, ніж просто використання функцій. Йдеться також про мінімізацію побічних ефектів та мутацію.

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

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