В чем разница между инкапсулированием частного члена как свойства и определением свойства без частного члена?

В чем разница (производительность, память … и т. Д.) Между инкапсулированием частного члена, подобного этому

private int age; public int Age { get { return age; } set { age = value; } } 

и определить свойство, подобное этому

 public int Age { get ; set ; } 

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

Единственное реальное отличие состоит в том, что он украшает свойство getter и setter с атрибутом [CompilerGenerated] . Это не должно влиять на производительность получения и настройки свойства. (В качестве незначительной nitpick это должно немного увеличить размер бинарной сборки сборки).

То, что мне нравится в автоматически реализованных свойствах, кроме краткости, конечно, состоит в том, что он не позволяет даже объявляющему типу доступа к фоновому полю вместо свойства (фоновое поле является анонимным). Это дает ясность коду и, как правило, упрощает реорганизацию / изменение реализации свойств.

Во втором случае компилятор C # генерирует для вас поле и генерирует getter и setter для доступа к нему. Другими словами, нет никакой функциональной разницы между двумя приведенными вами образцами кода. Единственным отличием будет имя частного поля, которое будет генерироваться компилятором.

Я задал этот вопрос некоторое время назад:

см. Правильное использование свойств C #

Цитирование ответа:

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

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

С точки зрения кодирования, я предпочитаю вторую версию, которая более компактна (меньше для записи, меньше для чтения).

Второй синтаксис был введен в C # 3.0. Таким образом, первый вариант будет более совместим со старыми компиляторами.

Разница в том, что у вас есть контроль над геттерами и сеттерами.

С автоматической реализацией вы не можете сделать что-то вроде:

 private int age; public int Age { get { return age; } set { if (age != value) { age = value; OnAgeChanged(EventArgs.Empty); } } } public event EventHandler AgeChanged; protected virtual void OnAgeChanged(EventArgs e) { var handler = AgeChanged; if (handler != null) handler(this, e); } 

Если вам это не нужно, автоматической реализации должно быть достаточно.

Главным преимуществом использования автоматической реализации свойства по сравнению с полем является то, что при использовании автоматической реализации свойств, а затем вы хотите изменить реализацию, например, выше, интерфейс вашего classа не изменяется.

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

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

  • В чем разница между свойством зависимостей и прикрепленным свойством в WPF?
  • Имущество и сеттеры
  • Почему нам нужны свойства в C #
  • C # настройка / получение свойств classа по имени строки
  • Обратный вызов, когда свойство зависимостей получает изменение xaml
  • Создание родового имущества
  • свойство classа маркировки c # как грязное
  • Свойство C # и параметр ref, почему нет сахара?
  • Почему у вас есть пустое свойство get set вместо использования переменной public?
  • Когда использовать val или def в чертах Scala?
  • Ошибка в classе Swift: свойство не инициализировано при вызове super.init
  • Давайте будем гением компьютера.