Зачем использовать простые свойства вместо полей в С#?

Возможные дубликаты:
Должен ли я использовать общедоступные свойства и частные поля или общедоступные поля для данных?
Разница между автоматическими свойствами и открытым полем в С# 3.0

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

Как

public int Foo { get; set; }

настолько невероятно отличается от

public int Foo;

Сверху моей головы я могу думать о нескольких практических различиях между ними:

Доступ к члену с использованием отражения (редкие и наиболее достойные отражающие алгоритмы будут учитывать разницу)
Вторая запись позволяет использовать поле в качестве допустимого параметра для параметров ref и out, что, по-видимому, будет преимуществом для использования версии поля
Поля не работают в Remoting (возможно, я никогда не использовал удаленный доступ, но я думаю, что они не будут)?

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

Ответ 1

Использование свойств имеет несколько отличительных преимуществ:

Это позволяет управлять версиями, если вам потребуется дополнительная логика. Добавление логики в приемник или сеттер не нарушит существующий код.
Он позволяет корректно работать с привязкой данных (большинство структур привязки данных не работают с полями).

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

Кроме того, вы упомянули:

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

Это не требует, чтобы ваш код был изменен, но он заставляет вас перекомпилировать весь ваш код. Переход с поля на свойство - это изменение API-интерфейса, которое потребует перекомпилировать сборку, которая ссылается на вашу сборку. Сделав это автоматическим свойством, вы можете просто отправить новый двоичный файл и поддерживать совместимость API. Это преимущество "версии", о котором я упомянул выше...

Ответ 2

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

public int Foo {get; protected set;}

Ответ 3

Свойство - это элемент языка, который логически представляет свойство вещи, моделируемой классом. Класс Car моделирует автомобиль; цвет - это свойство автомобилей; поэтому Color является свойством Car.

Поле - это элемент языка, который представляет деталь реализации этого класса. У вашего автомобиля нет "цветового поля", поэтому ваше представление в программе автомобиля не должно выставлять поле под названием "Цвет". Он может содержать частную информацию о реализации, в которой свойство Color реализуется с помощью поля, но это частная деталь реализации, а не общедоступная часть модели.

Ответ 4

В основном из-за соглашения.

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

Отражение приходит в него раз в то время, но очень редко. Некоторые типы сериализации основаны на свойствах.

Ответ 5

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