Дизайн ООП - Где/Когда делают Вас свойства Validate?

По моему опыту, проверка происходит там, где есть ввод от человека / пользователя. И это обычно происходит, когда вы позволяете своим методом что-то изменить. В вашем примере я бы пошел на проверку метода:

setName()

Так бывает, когда вы разрешаете ввод значений / значений параметров, которые оказываются методами установки .

Каждый объект должен убедиться, что его внутреннее состояние непротиворечиво, поэтому проверку лучше всего проводить до изменения внутреннего состояния - в методах установки объекта.

Это зависит от вашего стиля программирования, поскольку в Википедии есть более подробные объяснения, я просто коснусь поверхности и сделаю ссылку на Википедию. (Да, я ТАК ленив.: -))

ПРИМЕЧАНИЕ: Все это НЕ относится к пользовательскому вводу. Вы должны подтвердить это в любом случае. Я просто говорю о классах бизнес-логики, которые никоим образом не должны сочетаться с пользовательским вводом. : -)

• Защита

Как уже упоминалось другими, вы будете обеспечивать соблюдение каждого свойства в его пределах. Я часто бросал исключения времени выполнения (Java), чтобы указать на эти сбои.

Википедия по защитному программированию

• По контракту

Вы документируете требования своего кода и предполагаете, например, что значения, переданные вашим установщикам, действительны в отношении определенного контракта. Это избавит вас от большого количества шаблонного кода. Но поиск ошибок будет немного сложнее, если будет задано недопустимое значение.

Википедия по проектированию по контракту

Если вы контролируете код, использующий ваш класс, то вы должны проводить проверку еще до того, как попытаетесь манипулировать переменными объекта (через публичные свойства). Если вы предполагаете сценарий, в котором вы не знаете, как будет использоваться ваш класс, тогда да, вы должны проверять свойства, это более или менее то, для чего они предназначены. Очевидно, это предполагает, что определение "является ли имя допустимым" является статическим бизнес-правилом, присущим объекту.

Проверка на обоих уровнях, конечно, самый безопасный путь.

Короче говоря, всегда проверять. В конечном итоге выполняйте все проверки сразу, а не «по ходу». Это поможет вашему коду оставаться оптимизированным и поможет устранить путаницу.

Важной частью ООП является также постоянное поддержание вашего объекта в допустимом состоянии. Следовательно, проверка должна выполняться после ввода, который может изменить объект.

Всегда хорошо проверять данные, поступающие из свойств / набора, параметров в функции и конструктор.

Важно различать валидность в смысле инвариантов доменного объекта (которые всегда должны выполняться) и то, что некоторые люди называют « контекстной валидацией .« Например, является ли клиент с отрицательным банковским счетом« недействительным? »Нет, но он может не иметь права на выполнение определенных видов транзакций. Это контекстная проверка , в отличие от« каждый клиент сущность должна иметь ненулевой идентификатор, "что является совершенно другим типом проверки.

Один из эффективных методов обеспечения инвариантов состоит в том, чтобы различать классы, которые представляют вводимые пользователем данные, от объектов домена и не раскрывают неограниченные мутаторы (простые средства доступа к множеству) , например) в объектах домена.

Например, если у вас есть объект домена Student , не управляйте им непосредственно в пользовательском интерфейсе. Вместо создания Student экземпляров, ваши представления создают экземпляры StudentBuilder , которые моделируют то, что вам нужно для создания действительного объекта домена Student .

Затем у вас есть классы, которые проверяют, соответствуют ли экземпляры построителя инвариантам объекта домена , и фабрики, которые принимают строители и могут преобразовывать их в допустимые объекты домена. (Вы также можете ввести стратегии контекстной проверки на этом этапе по мере необходимости.)