OOP Design - Где/когда вы проверяете свойства?

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

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

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

Итак, как вы это гарантируете? У вас есть "метод проверки достоверности" вместе с каждым геттером и сеттер?

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

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

ОТВЕТЫ

Ответ 1

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

setName()

Итак, это происходит там, где вы допускаете ввод значений/значений настроек, которые оказываются методами setter.

Ответ 2

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

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

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

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

Ответ 3

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

Ответ 4

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

Ответ 5

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

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

Ответ 6

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

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

Ответ 7

Это зависит от вашего стиля программирования, поскольку Wikipedia имеет более подробные объяснения. Я просто поцарапаю поверхность и ссылку на Википедию. (Да, я ЛЮБЛЮ.: -))

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

  • Оборонительный

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

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

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

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

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