Что геттеры и сеттеры должны и не должны делать [дубликаты]

Мой вид:

1. Если ожидается, что сеттер или геттер будет дорогим, не делайте его свойством, сделайте его методом.

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

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

4. Доступ к свойству может иметь побочные эффекты, если они не являются неожиданными и не имеют значения. Это означает, что создание экземпляра JIT в геттере в порядке. Точно так же установка грязного флага для экземпляра всякий раз, когда вносятся изменения, вполне допустима, так как при этом устанавливается связанное свойство, например, другой формат для одного и того же значения.

5. Если он что-то делает, а не просто обращается к значению, это должен быть метод. Method — это глаголы, поэтому создание соединения будет выполняться методом OpenConnection(), а не свойством Connection. Свойство Connection будет использоваться для получения используемого соединения или для привязки экземпляра к другому соединению.

изменить – добавить 5, изменить 2 и 3

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

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

То же и с событиями. Если установщик генерирует событие, говорящее, что «это свойство изменилось», то все в порядке, потому что это очевидный побочный эффект. Но если он запускает какое-то другое пользовательское событие, вызывая выполнение какого-то скрытого фрагмента кода в другой части системы, это плохо.

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

Я всегда считал консервативный подход лучшим, когда работаю на C#. Поскольку свойства синтаксически такие же, как и поля, они должны работать как поля: никаких исключений, никакой проверки, никаких шуток. (Действительно, большинство моих свойств начинаются как простые поля и не становятся свойствами до тех пор, пока они не станут абсолютно необходимыми.) Идея состоит в том, что если вы видите что-то, похожее на получение или установку набора полей, то это ЯВЛЯЕТСЯ чем-то вроде получения или установка поля с точки зрения функциональности (никаких исключений), общей эффективности (например, установка переменных не запускает каскад вызовов делегатов) и влияния на состояние программы (установка переменной устанавливает эту переменную, а не не вызывает множество делегатов, которые могут делать что угодно).

Разумные вещи для набора свойств включают установку флага, указывающего, что произошло изменение:

set {
    if(this.value!=value) {
        this.changed=true;
        this.value=value;
    }
}

Возможно, на самом деле установите значение для другого объекта, например:

set { this.otherObject.value=value; }

Возможно, немного распутать ввод, чтобы упростить внутренний код класса:

set {
    this.isValid=(value&Flags.IsValid)!=0;
    this.setting=value&Flags.SettingMask;
}

(Конечно, в этих двух последних случаях функция get вполне может делать обратное.)

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