CSharp: свойство или публичное поле

Опубликовано 16.05.2022 12:01:00 в категории Просто о NET

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

Вопрос

Что лучше использовать Свойства vs Публичные поля (property vs public field)?

То есть надо определить, что предпочтительнее использовать. Таким образом:

/// <summary>
/// Пример авто свойства
/// </summary>
public string AutoProperty { get; set; }

или таким образом:

/// <summary>
/// Пример публичного поля
/// </summary>
public string Field;

Определение

Из описания авто свойства на сайте Microsoft:

В C# 3.0 и более поздних версиях автоматически реализуемые свойства делают объявление свойств более лаконичным, когда в методах доступа к свойствам не требуется дополнительная логика. Они также позволяют клиентскому коду создавать объекты. При объявлении свойства, как показано в следующем примере, компилятор создает закрытое анонимное резервное поле, которое может быть доступно только через методы доступа get и set свойства. В C# 9 и более поздних версий методы доступа init также можно объявить, как автоматически реализуемые свойства.

Ответ

Не буду вдаваться в подробности, просто разложу ответ на плюсы и минусы:

Тезисы в пользу использование public field

  • Используется меньше кода

Тезисы в пользу использование property

  • Вы не можете привязать данные к полю, в то время как вы можете к свойству
  • Если вы начнете использовать поле, вы не сможете позже (легко) изменить их на свойство
  • Существуют некоторые атрибуты, которые можно добавить в свойство, которое нельзя добавить в поле
  • Свойства позволяют устанавливать различные уровни доступа для getter и setter, что вы не можете сделать с полем
  • Нет возможности использовать открытые поля в определении интерфейса, а свойства это позволяют сделать
  • Даже если вы начнете с публичного поля, а потом, когда вам захочется (или придётся) превратить его в публичное свойство — это будет считаться критическим обновлением, потому что это есть изменение контракта API (versioning частично решает проблему). И этот рефакторинг сделать порой очень не просто (не быстро).
  • Быстрое создание через code snippet
  • Свойства, даже авто-свойства, могут быть виртуальными и абстрактными, а поля нет
  • Отладчик CLR не поддерживает точки останова (breakpoint) на определении полей. Для свойства вы можете установить и для чтения, и для записи свойства. Это очень полезно в некоторых сценариях отладки. Хотя в последних версиях, кажется, уже можно ставить точки останова на полях.
  • У вас не получится использовать модификатор readonly для публичного поля, а для свойства это в порядке вещей

Итоги

Есть что дополнить? Пишите в комментарии ваше тезисы, я обязательно дополню списки.

Комментарии к статье ()

Загрузка...

Что-то пошло не по сценарию и завершилось ошибкой. Перезагрузить страницу (F5) 🗙

Переподключаем сервер...

Переподключение сломалось... Пробуем еще раз сек.

Не получилось переподключится.
Пожалуйста, обновите страницу F5

Сессия была поставлена сервером на паузу.

Восстановить сессию не получилось.
Пожалуйста, обновите страницу F5.