Я не говорил, что скала плоха. Но это сложный язык. Начнем с того, что он мультипарадигменный, а не чисто ФП, как haskell. И многие возможности, нужные для ФП(те же type class) "эмулируются" с использованием других конструкций языка(неявных параметров в случае с type class).
Мне, например, после Java гораздо легче было учить hs чем scala. А уже с изучением hs стало понятно, зачем нужны все эти странные, на первый взгляд, конструкции в scala.
Что бы понять, надо хотя-бы попробовать, а не делегировать умственную деятельность комментаторам на хабре. За всё время Вы бы могли уже сто раз сами поиграться с компилятором haskell и вопросов бы не осталось.
Начинать со Scala, конечно, умное решение. Я бы ещё понял haskell.
Если интересует что такое монада с точки зрения ЯП, то это легко выяснить. Для монад есть instance (type)класса Monad, куда уж проще?
Это вполне конкретная программная сущность. Не сущность предметной области, а программная как переменная или функция.
И? Методы rich модели тоже программная сущность. Можно вообще не создавать программные сущности, просто делать прямые запросы sql. Так что ни разу не аргумент.
И rich модель не ставит запретов на создание сервисов, он предполагает лишь, что в большинстве случае в рамках одного метода вызывается только один метод сущности, если утрировать. Ну и нужность сервисов, в методах которых только методы сущности и вызывается и ничего больше, под большим вопросом.
Так речь не о запретах создания сервисов. Речь о том, что rich модель усложняет работу с состояниями для пользователей бизнес слоя.
Service это не отдельная сущность, это просто контекст для выполнения функций, которые проводят операции с контрактом. Этот контекст знает о persistence, например. И сам класс Contract это не сущность, это просто представление сущности, их может быть множество. Сущность скрывается за совокупностью представлений и операций над ними.
Таким образом я могу получить представление SignedContract, например, у которого будут заполнены поля signatory и signDate, не имеющие смысл при других состояниях контракта. И сделать функции с другими контекстами(сервисы), которые оперируют только с подписанным котрактом, например.
Плюс я могу сделать отдельный сервис для расчётов, который будет рассчитывать, например, графики платежей для разных состояний (кредитного)контракта, не изменяя при этом его реальное состояние.
В rich же модели сложнее сказать что и когда меняется в реальном состоянии, тем более если есть ссылки на другие сущности.
Сервис в бизнес-слое для элементарных операций над одной сущностью, не затрагивающих ничего больше.
Сервис это деталь реализации, такая же, как какая-нибудь фабрика или тот же entityManager. По сути сервис представляет собой просто набор функций, которые, безусловно, основаны уже на реальных операциях над данными.
А какое у вас? Идеологическое? :)
Видимо да, такое же, как и у вас.
Стейт один и тот же
«кишками наружу» означает, что стейт всё-таки по большей части отделён от функций. Его проще, например, подменить для тестов. Или использовать для расчётов, не изменяя настоящую сущность. Например, я хочу посмотреть что поменяется, если я изменю в контракте один метод начисления процентов на другой. Как отработает функция на этом контракте. В rich модели мне придётся отдельно позаботиться, что-бы изменения не попали в БД.
Вот на уровне бизнес-логики как об этом помнить не обязательно в идеале.
приходится вспоминать, когда всплывают проблемы с ленивостью, например.
Анемичная модель заставляет вводить в программный код абстракции, которых в реальном мире (в том числе в UI) не существует
о каких абстракциях речь? Думаю, анемичность модели никак не коррелирует с реальностью описываемых ей объектов.
которые даже технически ничем не обусловлены кроме желания сделать сущности ORM простыми DTO передающими данные в БД из слоя бизнес-логики, атрофировавшегося в слой бизнес-сервисов
а кто сказал, что здесь должно быть именно техническое обоснование?
Могу предположить что анемичная модель обычно стремится к stateless. В то время как rich больше про модификацию состояния сущности, что в свою очередь накладывает отпечаток на тестируемость и работу в многопоточной среде.
Как, например, передать сущность, по которой были проведены какие-то операции, в другой поток, для продолжения дальнейших действий?
Плюс нужно всегда помнить, что сущность управляется entityManager, и это обусловлено именно persistence.
Нет, начинал я не с hibernate, тут другие соображения.
Я отошел от представления о том, что ООП лучше чем не ООП, и(в следствии) об анемичной модели как об антипаттерне.
Я не претендую на истину в последней инстанции, возможно Вы правы, и мне стоит тчательнее изучить такой подход.
Просто пока я считаю что пользователи слоя бизнес логики не должны знать про hibernate, жизненный цикл сущностей и прочие вещи, связанные с БД(А это _обязательно_ нужно будет знать).
И сохранить сущность как простой интерфейс взаимодействия с БД, без собственного поведения, видится мне правильным.
Почти ООП, недоооп. Вы наверное знаете что и Java это не ООП, ведь в смолтолке все не так. Не существует единого определения ООП, как и самого понятия. А про переход — его небыло не потому, что не появлялись языки с новым на то время маркетинговым термином. Аналогичные подходы были всегда там, где они уместны. Современное же ООП — это пихание одинакового подхода со смешиванием функций и данных туда, где это не работает и не нужно. И смещение фокуса с реальных проблем на разделение ответственности между объектами.
Я уже сказал, это считается плохой практикой. Как минимум логика размазывается между сервисами и объектами слоя данных.
Ирония в том что почти все перечисленные технологии оперируют не с объектами.
На словах всё идеально, конечно.
Но по факту все проблемы, озвученные мной в силе.
Разделение на данные и функции не требуется — но REST по другому не работает.
Сущности hibernate всё ещё относятся к слою данных, и никто в них поведения(связанного с логикой) не закладывает. Это считается плохим тоном, да и бинами spring эти сущности не являются.
Единственный нормальный вариант — это возвращать ValueObject'ы из сервисов бизнес логики. И у нас просто функции + данные. Но даже если этого не делать — всё равно разделение всплывает на уровне REST.
В итоге проблемы нет — правда приходится делать 10 слоёв с преобразованиями, получая не ОО код/api, но это так — мелочи. ООП, что бы это ни было, работает!
Вот как раз переход от передачи дескрипторов в функции к инкапсуляции дескриптора и функций в одной программной сущности и есть переход от ПП к ООП. Один из аспектов этого перехода, точнее.
По мне так никакого перехода не было. И ООП суть ПП, за исключением некоторых не принципиальных нюансов.
ООП — достаточно конкретная комбинация принципов инкапсуляции, наследования (как механизма образования подтипов объектов) и полиморфизма этих подтипов.
Наследование совсем не обязательно, иерархию подтипов можно организовать с помощью утиной типизации, например.
В итоге у нас просто полиморфизм подтипов + инкапсуляция. Причём инкапсуляция совсем не уникальна для ООП, так что с конкретикой я бы поспорил. ООП это не что-то конкретное и чётко определённое.
Я в последнее время вообще редко встречаю следы продуманного дизайна, кроме навязанного выбранного платформой. :( Иногда навязывание даже не техническое, а просто примеры в документации для демонстрации одного аспекта, трактуется как универсальные, что так надо писать всегда.
Тут полностью соглашусь, это как раз и стало отправной точкой в моих сомнениях насчёт ООП как парадигмы.
Так вопрос как раз в межпроцессном взаимодействии. Оно как раз и требует этого строгого разделения. В итоге мы берём данные из базы, смешиваем с функциями, что-бы потом вновь всё разделить для межпроцессного взаимодействия.
Сокрытие это всего-лишь один из механизмов, которым можно обеспечить инкапсуляцию. И инкапсуляция в том или инном виде есть во всех парадигмах. С начала времён существовали различные вещи вроде дескрипторов, они тоже Объектно Ориентированны, получается?
Наследование даже не упоминаю т.к. это всего-лишь механизм, а не концепция.
Полиморфизм _подтипов_ — это то, что выделяет ООП? Но ведь есть ещё миллион разных полиморфизмов, почему бы под каждый не сделать N-ориентированное программирование?
Могут быть отклонения типа DTO/VO или stateless сервисов, но это именно отклонения. Если таких отклонений большинство в программе, то
В последнее время такой дизайн я встречаю чаще, чем «объектно ориентированный».
По факту, Entity слой бизнес-логики, прозрачно декорированный слоём persistence.
Я так не считаю, здесь мы расходимся во мнениях.
Вся бизнес-логика логика в сущностях и бизнес-сервисах. Их публичные методы гарантируют соблюдение бизнес-правил модели бизнеса. А DTO лишь для передачи данных между слоями приложения и UI в первом варианте, и бизнес-логики и приложения во втором.
DTO в любом случае существуют, а значит нам всё равно придётся уходить от ООП, явно разделяя функции(методы, функции с контекстом) и данные. Это то, о чём я говорил в начале — концепция объединения данных и поведения в итоге не работает. Мы получаем данные, смешиваем их с поведением, что-бы потом вновь разделить. В итоге мы просто делаем лишнюю работу.
Знаю что для android разработки часто используют обфускацию, вы используете это и для enterprise web?
Не я это придумал, и с этим часто бывают проблемы, но да — как-то так.
Выглядит как черная магия и призыв драконов. Понятно, что все дело в практике, но мне кажется синтаксис не должен быть слишком пугающим и магическим. Лучше сделать что-то явно, чем неявно.
Да нет, вполне простой синтаксис. К тому же надо учитывать что это не отдельный специальный синтаксис, всё реализовано средствами языка. И неявного здесь ничего нет.
Но за кадром остается много других вещей. Насколько гибче получится сделать микросервис принимающий данные с клиента, обрабатывающий эти данные и сохраняющий их в БД?
Если честно, я не так много сервисов делал на haskell, в основном пробовал разные библиотеки и подходы. Естественно приходилось всё изучать и сложно сравнивать по скорости разработки со знакомой мне java. Но саму логику писать довольно просто, для БД есть persistent, изменять структуры данных особой проблемы не составляет.
Обычно программы представляют собой описание DSL языков, и весь бизнес слой представляет собой такой спецефический язык. При этом всё это проще ложится на REST.
Я не говорил, что скала плоха. Но это сложный язык. Начнем с того, что он мультипарадигменный, а не чисто ФП, как haskell. И многие возможности, нужные для ФП(те же type class) "эмулируются" с использованием других конструкций языка(неявных параметров в случае с type class).
Мне, например, после Java гораздо легче было учить hs чем scala. А уже с изучением hs стало понятно, зачем нужны все эти странные, на первый взгляд, конструкции в scala.
Начинать со Scala, конечно, умное решение. Я бы ещё понял haskell.
Если интересует что такое монада с точки зрения ЯП, то это легко выяснить. Для монад есть instance (type)класса Monad, куда уж проще?
Так речь не о запретах создания сервисов. Речь о том, что rich модель усложняет работу с состояниями для пользователей бизнес слоя.
Таким образом я могу получить представление SignedContract, например, у которого будут заполнены поля signatory и signDate, не имеющие смысл при других состояниях контракта. И сделать функции с другими контекстами(сервисы), которые оперируют только с подписанным котрактом, например.
Плюс я могу сделать отдельный сервис для расчётов, который будет рассчитывать, например, графики платежей для разных состояний (кредитного)контракта, не изменяя при этом его реальное состояние.
В rich же модели сложнее сказать что и когда меняется в реальном состоянии, тем более если есть ссылки на другие сущности.
Видимо да, такое же, как и у вас.
«кишками наружу» означает, что стейт всё-таки по большей части отделён от функций. Его проще, например, подменить для тестов. Или использовать для расчётов, не изменяя настоящую сущность. Например, я хочу посмотреть что поменяется, если я изменю в контракте один метод начисления процентов на другой. Как отработает функция на этом контракте. В rich модели мне придётся отдельно позаботиться, что-бы изменения не попали в БД.
приходится вспоминать, когда всплывают проблемы с ленивостью, например.
а кто сказал, что здесь должно быть именно техническое обоснование?
Могу предположить что анемичная модель обычно стремится к stateless. В то время как rich больше про модификацию состояния сущности, что в свою очередь накладывает отпечаток на тестируемость и работу в многопоточной среде.
Как, например, передать сущность, по которой были проведены какие-то операции, в другой поток, для продолжения дальнейших действий?
Плюс нужно всегда помнить, что сущность управляется entityManager, и это обусловлено именно persistence.
Нет, начинал я не с hibernate, тут другие соображения.
Я отошел от представления о том, что ООП лучше чем не ООП, и(в следствии) об анемичной модели как об антипаттерне.
Просто пока я считаю что пользователи слоя бизнес логики не должны знать про hibernate, жизненный цикл сущностей и прочие вещи, связанные с БД(А это _обязательно_ нужно будет знать).
И сохранить сущность как простой интерфейс взаимодействия с БД, без собственного поведения, видится мне правильным.
Чему нужно подтверждение? Что бизнес логика не должна находиться в слое persistence?
Почти ООП, недоооп. Вы наверное знаете что и Java это не ООП, ведь в смолтолке все не так. Не существует единого определения ООП, как и самого понятия. А про переход — его небыло не потому, что не появлялись языки с новым на то время маркетинговым термином. Аналогичные подходы были всегда там, где они уместны. Современное же ООП — это пихание одинакового подхода со смешиванием функций и данных туда, где это не работает и не нужно. И смещение фокуса с реальных проблем на разделение ответственности между объектами.
Я уже сказал, это считается плохой практикой. Как минимум логика размазывается между сервисами и объектами слоя данных.
Ирония в том что почти все перечисленные технологии оперируют не с объектами.
Но по факту все проблемы, озвученные мной в силе.
Разделение на данные и функции не требуется — но REST по другому не работает.
Сущности hibernate всё ещё относятся к слою данных, и никто в них поведения(связанного с логикой) не закладывает. Это считается плохим тоном, да и бинами spring эти сущности не являются.
Единственный нормальный вариант — это возвращать ValueObject'ы из сервисов бизнес логики. И у нас просто функции + данные. Но даже если этого не делать — всё равно разделение всплывает на уровне REST.
В итоге проблемы нет — правда приходится делать 10 слоёв с преобразованиями, получая не ОО код/api, но это так — мелочи. ООП, что бы это ни было, работает!
Наследование совсем не обязательно, иерархию подтипов можно организовать с помощью утиной типизации, например.
В итоге у нас просто полиморфизм подтипов + инкапсуляция. Причём инкапсуляция совсем не уникальна для ООП, так что с конкретикой я бы поспорил. ООП это не что-то конкретное и чётко определённое.
Тут полностью соглашусь, это как раз и стало отправной точкой в моих сомнениях насчёт ООП как парадигмы.
В терминах программирования, то что Вы описали это именно строгое разделение на функции и данные.
Наследование даже не упоминаю т.к. это всего-лишь механизм, а не концепция.
Полиморфизм _подтипов_ — это то, что выделяет ООП? Но ведь есть ещё миллион разных полиморфизмов, почему бы под каждый не сделать N-ориентированное программирование?
В последнее время такой дизайн я встречаю чаще, чем «объектно ориентированный».
Json или dto — не принципиально, все равно в итоге идет строгое разделение данные/функции
DTO в любом случае существуют, а значит нам всё равно придётся уходить от ООП, явно разделяя функции(методы, функции с контекстом) и данные. Это то, о чём я говорил в начале — концепция объединения данных и поведения в итоге не работает. Мы получаем данные, смешиваем их с поведением, что-бы потом вновь разделить. В итоге мы просто делаем лишнюю работу.
Да нет, вполне простой синтаксис. К тому же надо учитывать что это не отдельный специальный синтаксис, всё реализовано средствами языка. И неявного здесь ничего нет.
Если честно, я не так много сервисов делал на haskell, в основном пробовал разные библиотеки и подходы. Естественно приходилось всё изучать и сложно сравнивать по скорости разработки со знакомой мне java. Но саму логику писать довольно просто, для БД есть persistent, изменять структуры данных особой проблемы не составляет.
Обычно программы представляют собой описание DSL языков, и весь бизнес слой представляет собой такой спецефический язык. При этом всё это проще ложится на REST.