Проверка данных в Getter / Setter или в другом месте?

Question

Мне интересно, будет ли хорошей идеей сделать проверки в получателях и установщиках или в других местах кода.

Это может удивить вас, когда дело доходит до оптимизаций и ускорения ускорения кода, я думаю, вам не следует проводить проверки в методах получения и установки, а в коде, где вы re обновление ваших файлов или базы данных. Я не прав?

Answer 1

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

Если у вас есть Number, который может быть между 1 и 100, я бы определенно поместил что-то в установщик, который это проверяет, а затем, возможно, сгенерировал бы исключение, которое перехватывается кодом. Причина проста: если вы не делаете это в установщике, вы должны помнить, что ограничение от 1 до 100 каждый раз, когда вы устанавливаете его, что приводит к дублированию кода или, когда вы его забываете, приводит к недопустимому состоянию.

Что касается производительности, я с Кнутом здесь:

«Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла».

Answer 2

@ Terrapin, re:

Если все, что у вас есть, это куча [простых public set / get] свойства ... они также могут быть поля

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

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

Answer 3

Это зависит.

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

Answer 4

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

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

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

... они также могут быть полями

Answer 5

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

Answer 6

Мне нравится реализовывать IDataErrorInfo и помещать мою логику проверки в свойствах Error и this [columnName]. Таким образом, если вы хотите программно проверить, есть ли ошибка, вы можете просто протестировать любое из этих свойств в коде или передать проверку привязки данных в веб-формах, Windows Forms или WPF.

Свойство привязки WPF "ValidatesOnDataError" делает это особенно простым.

Answer 7

Возможно, вы захотите проверить Дизайн, управляемый доменом , Эрик Эванс. У DDD есть это понятие Спецификации:

... явное предикатное значение ОБЪЕКТЫ для специализированных целей. СПЕЦИФИКАЦИЯ является предикатом определяет, делает ли объект не удовлетворяют некоторым критериям.

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

Answer 8

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

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

Вам не нужна какая-либо проверка для получателя, потому что информация об объекте уже считается действительной.

Не сохраняйте проверку до обновления базы данных !! Лучше быстро провалиться .