ООП Дизайн - Где / Когда вы Проверяете свойства?

Question

Я прочитал несколько книг по ООП DDD / PoEAA / Gang of Four, и ни одна из них, похоже, не охватывает тему валидации - кажется, всегда предполагается, что данные верны.

Из ответов на этот пост я узнаю ( Вопрос разработки ООП - Проверка свойств ), что клиент должен пытаться установить только значение свойства valid для объекта домена.

Этот человек задал похожий вопрос, который остается без ответа: http://bytes.com/topic/php/answers/789086-php-oop-setters-getters-data-validation#post3136182

Так как же убедиться, что оно действительно? У вас есть «метод валидатора» рядом с каждым геттером и сеттером?

• isValidName ()
• SetName ()
• GetName ()

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

Answer 1

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

setName()

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

Answer 2

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

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

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

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

Answer 3

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

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

• Оборонительная

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

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

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

Answer 7

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