CSharp: свойство или публичное поле
Просто о NET | создано: 16.05.2022 | опубликовано: 16.05.2022 | обновлено: 13.01.2024 | просмотров: 2094 | всего комментариев: 2
Очень встречаю разные подходы по написанию кода, например использование публичных полей вместо свойств. В этой статье приведу доводы в пользу использования свойств, а не публичных полей.
Вопрос
Что лучше использовать Свойства vs Публичные поля (property vs public field)?
То есть надо определить, что предпочтительнее использовать. Таким образом:
/// <summary>
/// Пример авто свойства
/// </summary>
public string AutoProperty { get; set; }
или таким образом:
/// <summary>
/// Пример публичного поля
/// </summary>
public string Field;
Определение
Из описания авто свойства на сайте Microsoft:
get
и set
свойства. В C# 9 и более поздних версий методы доступа init
также можно объявить, как автоматически реализуемые свойства.Ответ
Не буду вдаваться в подробности, просто разложу ответ на плюсы и минусы:
Тезисы в пользу использование public field
- Используется меньше кода
Тезисы в пользу использование property
- Вы не можете привязать данные к полю, в то время как вы можете к свойству
- Если вы начнете использовать поле, вы не сможете позже (легко) изменить их на свойство
- Существуют некоторые атрибуты, которые можно добавить в свойство, которое нельзя добавить в поле
- Свойства позволяют устанавливать различные уровни доступа для
getter
иsetter
, что вы не можете сделать с полем - Нет возможности использовать открытые поля в определении интерфейса, а свойства это позволяют сделать
- Даже если вы начнете с публичного поля, а потом, когда вам захочется (или придётся) превратить его в публичное свойство — это будет считаться критическим обновлением, потому что это есть изменение контракта API (versioning частично решает проблему). И этот рефакторинг сделать порой очень не просто (не быстро).
- Быстрое создание через
code snippet
- Свойства, даже авто-свойства, могут быть виртуальными и абстрактными, а поля нет
- Отладчик CLR не поддерживает точки останова (
breakpoint
) на определении полей. Для свойства вы можете установить и для чтения, и для записи свойства. Это очень полезно в некоторых сценариях отладки. Хотя в последних версиях, кажется, уже можно ставить точки останова на полях. - У вас не получится использовать модификатор
readonly
для публичного поля, а для свойства это в порядке вещей
Итоги
Есть что дополнить? Пишите в комментарии ваше тезисы, я обязательно дополню списки.
Комментарии к статье (2)
Спасибо зп родроное изложениея плюсов и минусов использования полеей и свойств.
Спасибо Сергей, хороший простой материал. Удачное сравнение. Легко позволяет сделать вывод разработчику, что использовать для большей гибкости. Когда-то сам использовал поля для коротких простых проектов, однако когда проекты стали побольше, произвел рефакторинг и обернул там где надо в свойства. Замечание по изменению контракта интересное. Если не ошибаюсь, на практике это для property info поле или свойство, при одинаковом условии доступности, setter и getter отрабатывают одинаково, но это не точно.