Если сеттер немедленно возвращается, если ему присвоено то же значение?

В классах, реализующих 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;

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

Кроме сохранения некоторых CPU/RAM/etc, освобождая пользовательский интерфейс от обновления чего-то, что, вероятно, будет выглядеть одинаково на экране /what _medium, что мы получим?

Могут ли некоторые люди принудительно обновить, переназначив одно и то же значение в свойстве (НЕ ТО, ЧТО ЭТО БЫЛО ХОРОШЕЙ ПРАКТИКИ ОДНАКО)?

1. Должны ли мы это делать или не должны мы?

2. Почему?

ОТВЕТЫ

Ответ 1

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

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

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

Ответ 2

Или вы можете это сделать:

   set
    {
        if (value != _customer.FirstName)
       {

           _customer.FirstName = value;

          base.OnPropertyChanged("FirstName");
       }
    }

Не нужно использовать несколько путей возврата.

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

Ответ 3

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

Ответ 4

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

Если эта ситуация не влияет на вас, тогда кешируйте!

<суб > Editсуб >

Я неправильно понял ваш вопрос, поскольку вы говорите о сеттерах, а не getters.

Аналогичные моменты применяются. Если заданная операция является дорогостоящей и не должна иметь какого-либо побочного эффекта (это не должно быть) Побочные эффекты на сеттерах <blink> зло </blink>!! 1), то это действительная оптимизация.

Ответ 5

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