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

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

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

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

2. Почему?

12
c# inotifypropertychanged properties setter

5 ответов

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

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

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

9

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

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

           _customer.FirstName = value;

          base.OnPropertyChanged("FirstName");
       }
    }

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

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

7

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

2

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

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

редактировать

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

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

1

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

1