Не получится, т.к. в новом Kinect'е (который в XBox One) стоит пульсомер — подделать колебания цвета поверхности монекена — это уже из разряда фантастики, так что готовимся, будущее грядет )
Полностью согласен. Liskov substitution principle понятен и композиция тоже нравится больше наследования, просто тут вопрос был в другом — при том или ином подходе более или менее ООП'шно ли решение.
По идее внутреннее состояние менять может только сама модель, ни один сервис, в том числе и репозиторий, не имеет доступа к внутреннему состоянию, а работает только с «интерфейсом» публичных свойств и методов (грубо говоря, сервис не может изменить приватную переменную объекта)
Имел ввиду свойства. Закрытые переменные, конечно, сервис изменить не сможет, но если сервису это будет нужно, то переменная превратиться в открытое свойство. Не встречал необходимости что-то прятать в anemic'е от сервисов. Может у Вас есть подходящий пример?
В ООП объекты могут обладать не только данными, но и действиями / методами, это известно всем и на этом строится собственно весь ООП (инкапсуляция, наследования и тп)
Крайне редко сущности моделируют что-то содержащее поведение — ордер, инвойс, клиент и пр. — это не модели с поведениями, а скорее документы с информацией о реальных ордерах, инвойсах и пр. Документы не содержат своего поведения.
Даже в играх, где, казалось бы, поведение присутствует, его часто выносят в отдельные классы — я специально интересовался на эту тему у игроделов. Человек, конечно, может сам иметь метод «сесть в транспортное средство», но как правило, за эту логику отвечает отдельный сервис, который знает как конкретному человеку содиться в конкретное транспортное средство и задействует для этого несколько модулей, в т.ч. проигрыватель анимации. Конечно, можно в методе Person.SeatInTheTransport() вызывать этот самый сервис, но это не более ООП'шно, на мой взгляд.
Сервисы не могут менять внутреннее состояние модели.
Тут под сервисами имелись ввиду репозитории, а они могут менять состояние. Да и сервисам домена (из DDD) ничто не мешает менять состояние сущностей.
Вообще, DTO тема тоже отдельная. Уровень DTO зависит от сложности модели.
В вьюхих Вы используете DTO или сущности домена? Потому что DDD'шники любят там DTO, а это автоматически создает почти полную копию домена и чаще даже еще больше сущностей, т.к. одно и тоже надо отображать и так и этак и начинаются PersonWithPhotoDTO, PersonFullDto и пр. Я опять-таки не проив этого если данные передаются по сети на клиента, но даже тут можно не писать DTO, если клиента пишет ваша команда и клиент с серверной частью сильно связаны и не имеют нескольких версий протокола одновременно.
anemic model добавляет в жизнь программиста как минимум две «сущности»: модель и сервис, а domain подход, больше стремится к упаковыванию всего этого в модель
только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.
Очень интересно продолжить поиск истины, а то сколько этим занимаюсь, а все тема открыта ) Понятно, что разница может быть незначительной, т.е. по сути не важно как делать — rich или anemic, но более детально рассмотреть плюсы и минусы всегда полезно )
А можно поподробнее о вопросах собеседований? Что спрашивали и что слышали / хотели услышать?
На счет того, что anemic менее ООП — это вопрос еще тот )
Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?
Как измерить степень ООП?
Потом, у самой сущности (ее пропертей) и у ее логики может быть разное время жизненного цикла.
При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.
Я не против DTO, но только когда сущность покидает границы приложения (или даже команды разработчиков).
Ну и в завершение: Cohesion wiki
Communicational cohesion — это логика в сущностях домена.
Functional cohesion (best) — это логика в сервисах домена или в репозиториях (слое доступа к данным).
зы не холивара ради, надеюсь на логичную аргументацию.
Подскажите, пожалуйста, примеры open source приложений с Rich Domain — очень хочется посмотреть на реально работающий код.DDDSample, естественно, не в счет. Так же интересен пример BDD. Сам найти не смог.
При anemic'е все проблемы решаемы — если классов сущностей очень много — можно их разделять на области.
Повторное использование кода, как в примере с документом, тоже возможно, но в не в иерархии сущностей домена, а в иерархии репозиториев (слой доступа к данным).
Но самая главная проблема rich, которая озвучена, но не вынесена в отдельный пункт — это:
Более того, вы не застрахованы от ошибки при моделировании, что может привести к сложному рефакторингу.
потому что пути заказчика и его бизнеса неисповедимы и Enterprise разработка отличается частыми и ощутитмыми изменениями требований, а рефакторить rich домен в такой ситуации становится довольно затратно и рефакторится он в сторону anemic.
Вообще тема холиварная )
О, это мне тоже больше нравится.
А как FXML и JavaFX Script соотносятся?
Просто разные инструменты для создания разметки? Функциональных ограничений нет?
зы Сам в java не силен, но интересно.
Больше подробностей, а то что-то не сходится.
Интересная аббревиатура )
Руководитель проектов и арт-директор веб-студии Spacebox.
Кажется, я знаю почему у Вас такое отношение )
Поэтому мой лозунг — «Прежде чем писать код — думай, блять!» )
Даже в играх, где, казалось бы, поведение присутствует, его часто выносят в отдельные классы — я специально интересовался на эту тему у игроделов. Человек, конечно, может сам иметь метод «сесть в транспортное средство», но как правило, за эту логику отвечает отдельный сервис, который знает как конкретному человеку содиться в конкретное транспортное средство и задействует для этого несколько модулей, в т.ч. проигрыватель анимации. Конечно, можно в методе Person.SeatInTheTransport() вызывать этот самый сервис, но это не более ООП'шно, на мой взгляд.
Тут под сервисами имелись ввиду репозитории, а они могут менять состояние. Да и сервисам домена (из DDD) ничто не мешает менять состояние сущностей.В вьюхих Вы используете DTO или сущности домена? Потому что DDD'шники любят там DTO, а это автоматически создает почти полную копию домена и чаще даже еще больше сущностей, т.к. одно и тоже надо отображать и так и этак и начинаются PersonWithPhotoDTO, PersonFullDto и пр. Я опять-таки не проив этого если данные передаются по сети на клиента, но даже тут можно не писать DTO, если клиента пишет ваша команда и клиент с серверной частью сильно связаны и не имеют нескольких версий протокола одновременно.только Rich DDD взамен плодит целых два упомянутых слоя — Mappings и DTO's.
Очень интересно продолжить поиск истины, а то сколько этим занимаюсь, а все тема открыта ) Понятно, что разница может быть незначительной, т.е. по сути не важно как делать — rich или anemic, но более детально рассмотреть плюсы и минусы всегда полезно )
На счет того, что anemic менее ООП — это вопрос еще тот )
Какая разница в какой иерархии будет наследование в сущностях домена или в сервисах?
Как измерить степень ООП?
Потом, у самой сущности (ее пропертей) и у ее логики может быть разное время жизненного цикла.
При маппинге в DDD возникает слой с кучей DTO, которые являются дублированием сущностей домена.
Я не против DTO, но только когда сущность покидает границы приложения (или даже команды разработчиков).
Ну и в завершение:
Cohesion wiki
Communicational cohesion — это логика в сущностях домена.
Functional cohesion (best) — это логика в сервисах домена или в репозиториях (слое доступа к данным).
зы не холивара ради, надеюсь на логичную аргументацию.
При anemic'е все проблемы решаемы — если классов сущностей очень много — можно их разделять на области.
Повторное использование кода, как в примере с документом, тоже возможно, но в не в иерархии сущностей домена, а в иерархии репозиториев (слой доступа к данным).
Но самая главная проблема rich, которая озвучена, но не вынесена в отдельный пункт — это:
потому что пути заказчика и его бизнеса неисповедимы и Enterprise разработка отличается частыми и ощутитмыми изменениями требований, а рефакторить rich домен в такой ситуации становится довольно затратно и рефакторится он в сторону anemic.
Вообще тема холиварная )
зы Естественно, imho.
А как FXML и JavaFX Script соотносятся?
Просто разные инструменты для создания разметки? Функциональных ограничений нет?
зы Сам в java не силен, но интересно.