Метод set должен сразу возвратить, если присвоено то же значение?
В классах, которые реализуют INotifyPropertyChanged, я часто вижу этот шаблон:
public string FirstName
{
get { return _customer.FirstName; }
set
{
if (value == _customer.FirstName)
return;
_customer.FirstName = value;
base.OnPropertyChanged("FirstName");
}
}
Точно строки
if (value == _customer.FirstName)
return;
беспокоят меня. Я имею, часто делал это, но я не то, что уверенный этому было нужно, ни хороший. В конце концов, если вызывающая сторона присваивает то же самое значение, я не хочу повторно присваивать поле и, особенно, уведомлять моих подписчиков, что свойство изменилось, когда, семантически оно не сделало.
Кроме сохранения некоторого ЦП/RAM/и т.д. путем освобождения UI от обновления чего-то, что будет, вероятно, выглядеть одинаково на screen/whatever_medium, что мы получаем?
Некоторые люди могли вызвать обновление путем переприсвоения того же значения на свойстве (НЕ ТО, ЧТОБЫ ЭТО БЫЛО БЫ ХОРОШЕЙ ПРАКТИКОЙ ОДНАКО)?
1. Мы должны сделать это, или не были должны мы?
2. Почему?
5 ответов
Да, вы должны немедленно вернуться, когда потребитель устанавливает значение свойства, равное значению, которое уже сохраняется.
Прежде всего, нет причин тратить время или ресурсы на установщик свойства - значение уже установлено, поэтому никаких дальнейших действий не требуется. Также вы никогда не должны вызывать OnPropertyChanged , если значение, хранящееся в поддерживающем поле свойства, не изменилось - метод предназначен для срабатывания, когда значение изменилось , а не когда установщик свойства был вызван.
Однако все, что было сказано - если бы у установщика не было вызова OnPropertyChanged , я бы не стал сначала проверять значение. В случае простого установщика, который устанавливает только значение резервного поля и ничего больше, на самом деле будет быстрее всегда устанавливать значение, чем сначала проверять, а затем устанавливать значение. Используйте этот шаблон только в том случае, если установщик свойства имеет дополнительную логику, которая либо не должна срабатывать, либо может привести к ненужному снижению производительности.
Единственный аргумент против этого шаблона (где вы возвращаете, если значение не изменилось), о котором я могу думать, это мнение пуриста, что каждая функция должна иметь только один выход. Не будучи пуристом, я не согласен. Я не вижу ничего плохого в том, чтобы выйти из строя, если значение не изменилось, избегая обновления уведомлений.
Я полагаю, одна из причин не возвращаться раньше - для подписчиков, которые присоединились к вечеринке поздно. Они могут не знать о текущем состоянии объекта и пропустить уведомление установщика, если вы вернетесь раньше.
Единственная ситуация, когда вы не должны использовать его, - это когда вы знаете, что у вас могут быть грязные данные в вашем классе, например, в объекте уровня ORM, значения которого могут быть устаревшими по сравнению с базовой базой данных из-за модификации другим пользователем.
Если эта ситуация вас не коснется, то кэшируйте!
Edit
Я неправильно понял ваш вопрос, поскольку вы говорите о сеттерах , а не о геттерах .
Применяются аналогичные баллов. Если операция set является дорогостоящей и не должна иметь никаких побочных эффектов (это не должно быть! Побочные эффекты для сеттеров evil ] !! 1), то это правильная оптимизация.
Или вы можете сделать это:
set
{
if (value != _customer.FirstName)
{
_customer.FirstName = value;
base.OnPropertyChanged("FirstName");
}
}
Нет необходимости в нескольких путях возврата.
Чтобы ответить на ваш вопрос, я бы не стал принудительно обновлять свойство, если оно перезаписывается тем же значением. В этом нет никакого смысла, потому что вы, вероятно, не получите от этого никакой пользы. (Я видел пример, в котором вы хотели бы отслеживать каждый раз, когда кто-то пытается обновить значение.)