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

Question

В классах, которые реализуют 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 / и т. Д., Освободив пользовательский интерфейс от обновления чего-либо, что, вероятно, будет выглядеть на экране / what_medium, что мы получим?

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

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

2. Почему?

Answer 1

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

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

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

Answer 2

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

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

           _customer.FirstName = value;

          base.OnPropertyChanged("FirstName");
       }
    }

Нет необходимости в нескольких путях возврата.

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

Answer 3

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

Answer 4

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

Answer 5

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

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

---

_{Редактировать}

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

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