Какие Методы считывания и Методы set должны и не должны делать [копируют]
3 ответа
Мое мнение:
Если ожидается, что сеттер или получатель будут дорогими, не делайте его свойством, а методом.
Если установка свойства запускает события из-за изменений, это нормально. Как еще вы позволили бы слушателям получать уведомления об изменениях? Однако вы можете предложить пару BeginInit / EndInit для подавления событий до тех пор, пока не будут внесены все изменения. Обычно обработчик события обязан незамедлительно вернуться, но если вы действительно не можете ему доверять, вы можете сообщить о событии в другом потоке.
Если установка свойства вызывает исключения для недопустимых значений, это тоже нормально. Это разумный способ сообщить о проблеме, когда значение полностью неверно. В других случаях вы устанавливаете набор свойств, а затем вызываете метод, который использует их для каких-либо действий, например, для установления соединения. Это позволило бы отложить проверку и обработку ошибок до тех пор, пока свойства не будут использованы, так что свойства не должны будут ничего генерировать.
Доступ к свойству может иметь побочные эффекты, если они не являются неожиданными и не имеют значения. Это означает, что JIT-инстанцирование в получателе в порядке. Аналогичным образом, установка флага загрязнения для экземпляра всякий раз, когда вносятся изменения, вполне нормально, поскольку он устанавливает связанное свойство, например, другой формат для того же значения.
Если он делает что-то , а не просто получает доступ к значению, это должен быть метод. Метод - это глаголы, поэтому создание соединения будет выполняться методом OpenConnection (), а не свойством Connection. Свойство Connection будет использоваться для извлечения используемого соединения или для привязки экземпляра к другому соединению.
edit - добавлено 5, изменено 2 и 3
Я всегда считал, что консервативный подход лучше всего при работе на C #. Поскольку свойства синтаксически идентичны полям, они должны работать как поля: без исключений, без проверки, без забавных дел. (Действительно, большинство моих свойств начинаются с простых полей и не становятся свойствами до тех пор, пока это абсолютно необходимо.) Идея состоит в том, что если вы видите что-то, похожее на получение или установку набора полей, то это что-то вроде получения или установка поля с точки зрения функциональности (исключение не возникает), общей эффективности (например, установка переменных не запускает каскад вызовов делегатов) и влияния на состояние программы (установка переменной устанавливает эту переменную, а не t вызвать множество делегатов, которые могут делать что угодно).
Разумные вещи для набора свойств включают установку флага, указывающего, что произошло изменение:
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.) То же самое и с получателями; если вы возвращаете ссылку на что-то, это не проблема, но если вы создаете совершенно новый большой объект и заполняете его каждый раз при чтении свойства - не ахти.
Я согласен с идеей, что геттеры / настройки не должны иметь побочных эффектов, но я бы сказал, что они не должны имеют неочевидные побочные эффекты.
Что касается выдачи исключений, если вы устанавливаете для свойства недопустимое значение (в самом простом смысле), тогда исключения проверки допустимы. Однако, если установщик выполняет целую серию сложных проверок бизнес-правил или пытается отключиться и обновить другие объекты, или что-то еще, что может вызвать исключение, то это плохо. Но на самом деле эта проблема не связана с самим исключением, а скорее с тем, что установщик отключен и тайно выполняет много функций, которых вызывающий не мог (или не должен) ожидать.
То же и с событиями. Если сеттер генерирует событие, говорящее, что «это свойство изменено», тогда все в порядке, потому что это очевидный побочный эффект. Но если он запускает какое-то другое настраиваемое событие, вызывающее выполнение некоторого скрытого фрагмента кода в другой части системы, это плохо.
По этой же причине я избегаю отложенной загрузки в геттерах.Действительно, в большинстве случаев они могут упростить задачу, но в некоторых случаях они могут сделать вещи более запутанными, потому что всегда получается запутанная логика именно тогда, когда вы хотите, чтобы дочерние объекты были загружены. Обычно это просто еще одна строка кода для явной загрузки дочерних объектов при заполнении родительского объекта, и это может избежать большой путаницы в состоянии объекта. Но этот аспект может стать очень субъективным, и многое зависит от ситуации.