DDD и использование геттеров и сеттеров - PullRequest
Новая
       49

DDD и использование геттеров и сеттеров

10 голосов
/ 28 ноября 2011

Я прочитал несколько статей / постов, касающихся использования геттеров и сеттеров, и того, как они помогают победить цель инкапсуляции в объектах модели предметной области. Я понимаю логику отказа от использования сеттеров - вы позволяете клиентскому коду манипулировать атрибутами этого объекта вне контекста бизнес-правил и инвариантов объекта.

Теперь этот принцип все еще смущает меня. Например, что произойдет, если мне нужно изменить значение переменной-члена объекта? Например, если имя человека меняется, как я могу отразить это в модели? Сначала я подумал: ну почему бы не иметь функцию с именем «ChangeName», которая позволяет мне передать новое имя, и она, в свою очередь, может изменить внутреннюю переменную «name». Ну ... это просто сеттер, не так ли?

Что мне нужно уточнить - если бы мне пришлось полностью исключить сеттеры, то в ситуациях, подобных описанным выше, я должен полагаться исключительно на параметры конструктора? Должен ли я передать новое значение атрибута вместо старого значения атрибута через конструктор, после чего я смогу сохранить изменения, передав объект в любую имеющуюся у меня инфраструктуру сохранения?

Эти две статьи полезны в этом обсуждении:

  1. http://kellabyte.com/tag/ddd/
  2. http://typicalprogrammer.com/?p=23

1 Ответ

9 голосов
/ 28 ноября 2011

Ну, это классическая дискуссия.Здесь есть несколько других тем в переполнении стека.

Но.Get / Set (Auto Properties?) Не все плохо.Но они, как правило, заставляют вас создавать свои сущности как «мертвые» контейнеры данных, которые имеют только проп, а не методы.Признаки этого часто называют Анемическим Доменом - и имеют очень слабое поведение.Моя рекомендация:

  1. Старайтесь использовать опору как можно меньше.
  2. Старайтесь находить группы данных, которые принадлежат друг другу и ДОЛЖНЫ быть вместе, как бывшие.Имя, Отчество и Фамилия.Другой пример - почтовый индекс, город, улица.Эти данные лучше задавать методом.Это сводит к минимуму вероятность того, что ваша сущность будет недействительной.
  3. Часто данные, которые принадлежат друг другу, могут быть сгруппированы как объект Value.
  4. Дополнительные объекты Value имеют тенденцию выводить из вашей сущности более описательные методы, которыеявляются "глаголами" вместо ваших обычно "существительных" сущностей.
  5. Дополнительные методы для ваших объектов-значений также открывают для добавления большего поведения и, возможно, сокращения ваших "толстых" сервисов (возможно, у вас нет сервисов с слишкомсильно просочилась бизнес-логика ...).

Здесь есть еще что сказать ... но краткий ответ.Об установке данных в конструкторе: я делаю это, только если эта сущность не может «жить» / существовать без этих данных.Для сущности Персона я бы сказал, что Имя, возможно, не так важно.Но Номер социального обеспечения может быть кандидатом на данные конструктора.Или субъект Сотрудник должен иметь Компанию в конструкторе, просто потому, что сотрудник должен принадлежать компании.

...