Здравствуйте, alexsoff, Вы писали:

J>>Или вы хотите сказать что когда используете anemic модели, то пишите код на C# в функциональном стиле, а не в процедурном?

A>Я хочу сказать, что Anemic модель — шаг в сторону функционального программирования, а если и соблюдать иммутабельность для anamic моделей — то можно говорить, что это почти целевая точка движения современных языков.

Насчёт целевой точки, я бы добавил: если говорить про энтерпрайз, то долгое время властвовал подход анемичной модели с подачи Фаулера и Ко. Эта модель была ненастоящим ООП и ненастоящим процедурным, а неким бастардом, потом по мере распространения ФП этому бастарду в вкровь впрыснули ДНК функциональщины, но тоже не-по "настоящему", а в виде эпизодических функциональных вставок, типа "тут мы заменим итератор на стрим с лямбдой". Мне кажется, анемик властвовал в умах потому, что энтерпрайз ещё только формировался, а у всемирного программистского разума есть некое ограничение по мощности, и первые пару десятков лет этот разум был занят формированием базовых основ энтерпрайза и поиском оптимальных решений типичных проблем (продумывание разных видов архитеуктур — слоистых, луковых, гексагональных... придумыванием EE-паттернов, разработкой транзакционных механизмов, механизмов DI, отимистик и пессимистик блокировок и т.д.), и у этого всеобщего разума не хватало сил на качественное продумывание самой сердцевины — бизнес-логики, поэтому первое время порешили что наиболее простым решением будет сделать тупо анемик-классы "почти как во взрослом ООП", а бизнес-логику тупо кидать в "почти процедурные" бизнес-сервисные методы. Но сейчас многие типичные проблемы решены и всеобщий энтерпрайзный разум обратил внимание на реализацию бизнес-логики и решил что пора вводить взрослое ООП — и всё больше проектов начинает обращать внимание на DDD (и главное, иметь силы и компетенции чтобы это самое DDD реализовывать, правда с разной степенью успеха и похожести на оригинальный DDD). Допустим, взять типичные энтерпрайз проекты 20-10 летней давности — основные усилия команды разрабов в том время заключались в том, чтобы реализовать типичные задачи энтерпрайза (и были жуткеи случаи когда целые команды разрабов не владели ни понятием транзакционности, ни блокировок, и всё это выкатывалось на прод и уже на живом продукте внешние более опытные консультанты накатывали на продукт транзакции и прочие патчи, чтобы система работала как энтепрайз), а сейчас каждый средний энтерпрайз-разраб уже ориентируется в этих типичных энтерпрайзных проблемах и умеет их решать "на раз", не нагружая свой мозг, и может направить высвободившуюся ментальную энергию на проработку фишек DDD — "настоящий" ООП: агрегаты, поведение в объектах (вместо поведения в процедурных бизнес-методах как в анемик-модели) с сохранением инварианта, репозитории, единый язык и т.д. Хотя делается это часто отвратно (на прод выводятся проекты, где DDD реализован криво), т.к. разрабы ещё не освоили DDD в полной мере, знаю эту дисциплину не полностью (а она вообще непроста к освоению), но уже пишутся реальные проекты на нём, на хабре всё больше статей, т.е. культура разработки в плане DDD развивается, что только радует. Ситуация с DDD сейчас очень похожа на паттерны: в начале про них все говорили (даже были требования от бизнеса и аналитиков о применении конкретных паттернов, конечно же часто вообще не к месту), разрабы очень часто готовили их неправильно или вообще дальше разговоров дело не заходило, а сейчас паттерны являются частью обще культуры разработки. И получается, что DDD — это ещё одна целевая точка развития, в которой ФП играет лишь роль а-ля "замены итераторов на стримы+лямбды", а скажем иммутабельность в DDD имеет самостоятельную ценность и без ФП, а как одна из стратегий сохранения инварианта объекта или как многопоточный паттерн.

>> Я не спорю, что процедурная программа хуже ООП в плане понимания и поддержки, но я хочу сказать, что будущее все-таки за FP стилем

И/или за DDD, по причинам, описанным выше))

Здравствуйте, alexsoff, Вы писали:

J>>Или вы хотите сказать что когда используете anemic модели, то пишите код на C# в функциональном стиле, а не в процедурном?

A>Я хочу сказать, что Anemic модель — шаг в сторону функционального программирования, а если и соблюдать иммутабельность для anamic моделей — то можно говорить, что это почти целевая точка движения современных языков.

Насчёт целевой точки, я бы добавил: если говорить про энтерпрайз, то долгое время властвовал подход анемичной модели с подачи Фаулера и Ко. Эта модель была ненастоящим ООП и ненастоящим процедурным, а неким бастардом, потом по мере распространения ФП этому бастарду в кровь впрыснули ДНК функциональщины, но тоже не-по "настоящему", а в виде эпизодических функциональных вставок, типа "тут мы заменим итератор на стрим с лямбдой". Мне кажется, анемик властвовал в умах потому, что энтерпрайз ещё только формировался, а у всемирного программистского разума есть некое ограничение по мощности, и первые пару десятков лет этот разум был занят формированием базовых основ энтерпрайза и поиском оптимальных решений типичных проблем (продумывание разных видов архитеуктур — слоистых, луковых, гексагональных... придумыванием EE-паттернов, разработкой транзакционных механизмов, механизмов DI, отимистик и пессимистик блокировок и т.д.), и у этого всеобщего разума не хватало сил на качественное продумывание самой сердцевины — бизнес-логики, поэтому первое время порешили что наиболее простым решением будет сделать тупо анемик-классы "почти как во взрослом ООП", а бизнес-логику тупо кидать в "почти процедурные" бизнес-сервисные методы (да, был SOLID, но он слишком был абстрактен и скорее как база и предтеча появления DDD). Но сейчас многие типичные проблемы решены и всеобщий энтерпрайзный разум обратил внимание на реализацию бизнес-логики и решил что пора вводить взрослое ООП — и всё больше проектов начинает обращать внимание на DDD (и главное, иметь силы и компетенции чтобы это самое DDD реализовывать, правда с разной степенью успеха и похожести на оригинальный DDD). Допустим, взять типичные энтерпрайз проекты 20-10 летней давности — основные усилия команды разрабов в том время заключались в том, чтобы реализовать типичные задачи энтерпрайза (и были жуткеи случаи когда целые команды разрабов не владели ни понятием транзакционности, ни блокировок, и всё это выкатывалось на прод и уже на живом продукте внешние более опытные консультанты накатывали на продукт транзакции и прочие патчи, чтобы система работала как энтепрайз), а сейчас каждый средний энтерпрайз-разраб уже ориентируется в этих типичных энтерпрайзных проблемах и умеет их решать "на раз", не нагружая свой мозг, и может направить высвободившуюся ментальную энергию на проработку фишек DDD — "настоящий" ООП: агрегаты, поведение в объектах (вместо поведения в процедурных бизнес-методах как в анемик-модели) с сохранением инварианта, репозитории, единый язык и т.д. Хотя делается это часто отвратно (на прод выводятся проекты, где DDD реализован криво), т.к. разрабы ещё не освоили DDD в полной мере, знаю эту дисциплину не полностью (а она вообще непроста к освоению), но уже пишутся реальные проекты на нём, на хабре всё больше статей, т.е. культура разработки в плане DDD развивается, что только радует. Ситуация с DDD сейчас очень похожа на паттерны: в начале про них все говорили (даже были требования от бизнеса и аналитиков о применении конкретных паттернов, конечно же часто вообще не к месту), разрабы очень часто готовили их неправильно или вообще дальше разговоров дело не заходило, а сейчас паттерны являются частью обще культуры разработки. И получается, что DDD — это ещё одна целевая точка развития, в которой ФП играет лишь роль а-ля "замены итераторов на стримы+лямбды", а скажем иммутабельность в DDD имеет самостоятельную ценность и без ФП, а как одна из стратегий сохранения инварианта объекта или как многопоточный паттерн.

>> Я не спорю, что процедурная программа хуже ООП в плане понимания и поддержки, но я хочу сказать, что будущее все-таки за FP стилем

И/или за DDD, по причинам, описанным выше))