Чому модель анемічного домену вважається поганою в C # / OOP, але дуже важливою для F # / FP?

У публікації блогу на F # для розваги та прибутку написано:

У функціональному дизайні дуже важливо відокремити поведінку від даних. Типи даних прості та "німі". А потім окремо у вас є ряд функцій, які діють на ці типи даних.

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

Насправді в OOD недостатня поведінка навколо типу даних вважається поганою річчю і навіть має назву: " анемічна модель домену ".

Враховуючи, що в C # ми, здається, продовжуємо запозичувати F # і намагаємось написати код більш функціонального стилю; чому так, ми не запозичуємо ідею розділення даних / поведінки, і навіть вважаємо це поганим? Це просто те, що визначення не відповідає OOP, чи є конкретна причина, що це погано в C #, яка чомусь не застосовується у F # (а насправді є зворотною)?

.

Основна причина, на яку прагне FP, а C # OOP не в тому, що у FP акцент робиться на еталонній прозорості; тобто дані переходять у функцію і дані виходять, але вихідні дані не змінюються.

У C # OOP існує концепція делегування відповідальності, де ви делегуєте управління об'єктом на нього, і тому ви хочете, щоб він змінив власну внутрішню.

У програмі FP ви ніколи не хочете змінювати значення в об'єкті, тому мати функції, вбудовані у ваш об'єкт, не має сенсу.

Далі у FP у вас вищий поліморфізм, що дозволяє вашим функціям бути набагато більш узагальненими, ніж дозволяє C # OOP. Таким чином ви можете написати функцію, яка працює для будь-якої a, і тому вбудовувати її в блок даних не має сенсу; що б щільно пара методу так , що він працює тільки з конкретним видом з a. Така поведінка в C # OOP все добре і поширена, тому що ви взагалі не маєте можливостей абстрактно функціонувати, але у FP це компроміс.

Найбільша проблема, яку я бачив у моделях анемічного домену в C # OOP, полягає в тому, що ви отримуєте дублікат коду, оскільки у вас є DTO x і 4 різні функції, які здійснюють активність f до DTO x, оскільки 4 різних людей не бачили іншої реалізації . Коли ви кладете метод прямо на DTO x, то ці 4 людини бачать реалізацію f і використовують її повторно.

Анемічні моделі даних у повторному використанні коду перешкод C # OOP, але це не так у FP, оскільки одна функція узагальнена на стільки різних типів, що ви отримуєте більше повторного використання коду, оскільки ця функція може бути використана в більшій кількості сценаріїв, ніж функція, яку ви написав би для одного DTO в C #.

Як зазначається в коментарях , висновок типу є однією з переваг, на які покладається FP, щоб дозволити такий значний поліморфізм, і конкретно ви можете простежити це до системи типу Хіндлі Мілнера з алгоритмом виводу типу W; такого виводу типу в системі типів C # OOP було уникнено, оскільки час компіляції, коли додається висновок на основі обмежень, стає надзвичайно довгим завдяки необхідному вичерпному пошуку, деталі тут: https://stackoverflow.com/questions/3968834/generics-why -cant-the-compiler-infer-the-type-argument-in-this-case

Чому модель анемічного домену вважається поганою в C # / OOP, але дуже важливою для F # / FP?

У вашому запитання є велика проблема, яка обмежить корисність отриманих відповідей: ви маєте на увазі / припускаєте, що F # і FP схожі. FP - це величезне сімейство мов, включаючи символічне переписування термінів, динамічне та статичне. Навіть серед статично типових мов FP існує багато різних технологій для вираження доменних моделей, таких як модулі вищого порядку в OCaml та SML (які не існують у F #). F # є однією з цих функціональних мов, але особливо примітна тим, що вона є худорлявою і, зокрема, не забезпечує ні модулів вищого порядку, ні типів вищого типу.

Насправді я не міг почати розповідати вам про те, як виражаються доменні моделі в FP. Інша відповідь тут говорить конкретно про те, як це робиться в Haskell і зовсім не стосується Lisp (матері всіх мов FP), сім'ї мов ML або будь-яких інших функціональних мов.

чому так, ми не запозичуємо ідею розділення даних / поведінки, і навіть вважаємо це поганим?

Дженріки можна вважати способом розділення даних та поведінки. Дженріки з сімейства ML функціональних мов програмування не є частиною OOP. З #, звичайно, має дженерики. Тож можна стверджувати, що C # повільно запозичує ідею розділення даних та поведінки.

Чи просто те, що визначення не відповідає OOP,

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

Ознайомтеся з прикладом, який я навів тут .

чи є конкретна причина, що це погано в C #, яка з якихось причин не застосовується у F # (а насправді є зворотною)?

Будьте уважні до переходу з OOP на C #. C # ніде не є пуританічним щодо OOP, як інші мови. .NET Framework тепер рясніє генеричними, статичними методами і навіть лямбдами.

.

Відсутність типів об'єднання та відповідності шаблонів у C # робить це майже неможливим. Коли у вас є молоток, все виглядає як цвях ...

Я думаю, що в бізнес-додатку ви часто не хочете приховувати дані, оскільки відповідність шаблонів на незмінні значення велика, щоб забезпечити охоплення всіх можливих випадків. Але якщо ви реалізуєте складні алгоритми чи структури даних, ви краще приховуєте деталі реалізації, перетворюючи ADT (алгебраїчні типи даних) в ADT (абстрактні типи даних).