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

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

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

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

2. Почему?

Answer 1

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

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

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

Answer 2

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

Answer 3

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

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

      _customer.FirstName = value; 

      base.OnPropertyChanged("FirstName"); 
     } 
    } 

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

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

Answer 4

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

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

---

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

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

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

Answer 5

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