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

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

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

5.08.2008 19:51:29
8 ОТВЕТОВ
РЕШЕНИЕ

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

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

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

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

15
5.08.2008 19:59:39

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

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

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

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

1
5.08.2008 20:05:26
Не могли бы вы уточнить? Вы говорите, например, проверить на <5 &&> 0 в отдельном методе проверки? Тогда что именно ваши геттеры и сеттеры делают, а обычное поле - нет?
Boris Callens 30.09.2008 09:18:13

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

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

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

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

3
7.08.2008 21:44:40

По-разному.

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

3
5.08.2008 19:59:13

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

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

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

1
5.08.2008 20:03:46

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

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

1
7.08.2008 22:24:01

@Terrapin, re:

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

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

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

4
8.08.2008 00:11:02

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

1
23.09.2008 19:44:28