Кто-нибудь еще видел, как люди это делают:
private string _name;
public string Name{ get{ return _name; } set{ _name = value;}}Я понимаю использование аксессуаров, если вы собираетесь осуществлять какой-то контроль над тем, как он устанавливается или выполняет какую-то функцию на нем, когда есть get. Но если вы только собираетесь это сделать, почему бы просто не сделать переменную открытой для начала? Я что-то пропустил?
Если вы сделаете член публичным полем, вы не сможете впоследствии преобразовать его в свойство без изменения интерфейса для вашего класса. Если вы раскрываете его как свойство с самого начала, вы можете внести любые изменения в функции доступа к ресурсам, которые вам нужны, и интерфейс класса остается неизменным.
Обратите внимание, что с С# 3.0 вы можете реализовать свойство без создания поля поддержки, например:
public string Name { get; set; }
Это устраняет то, что в значительной степени является единственным оправданием для того, чтобы не внедрять публичные поля в качестве свойств в первую очередь.
Если вы определяете открытый интерфейс с свойством в сборке A, вы можете использовать этот интерфейс в сборке B.
Теперь вы можете изменить реализацию свойства (возможно, извлечение значения из базы данных вместо сохранения в поле). Затем вы можете перекомпилировать сборку A и заменить более старую. Сборка B будет работать отлично, потому что интерфейс не изменился бы.
Однако, если вы сначала начали с публичного поля и решили, что это не подходит, и вы хотели бы изменить реализацию и сделать это, вам нужно было преобразовать его в свойство, то это означало бы, что вы необходимо изменить сборку. Открытый интерфейс. Любые клиенты этого интерфейса (включая сборку B) также должны быть перекомпилированы и заменены, чтобы иметь возможность работать с этим новым интерфейсом.
Итак, вам лучше начать с свойства изначально. Это инкапсулирует реализацию свойства, в результате чего вы можете изменить его в будущем, не беспокоясь о том, что клиенты (включая сборку B) уже вышли в мире, используя сборку A. Потому что, если в мире уже есть клиенты с использованием сборки A, изменение интерфейса приведет к разрыву всех клиентов. Если они используются другой командой в вашей компании или другой компании, тогда они будут недовольны, если вы сломаете свои сборки, изменив свой интерфейс!
Идея заключается в том, что если вы используете аксессоров, базовую реализацию можно изменить без изменения API. Например, если вы решите, что при установке имени вам также необходимо обновить текстовое поле или другую переменную, ни один из ваших клиентских кодов не изменится.
Возможно, стоит отметить, что DataBinding в .NET также отказывается работать с публичными полями и требует свойств. Это может быть другой причиной.
Хорошая практика программирования. Это очень распространенная модель, которая соответствует методологиям проектирования OO. Открывая публичное поле, вы подвергаете внутренности тому, как эти данные хранятся. Использование открытого свойства вместо этого позволяет вам более гибко изменять способ хранения данных внутри себя и не нарушать общий интерфейс. Это также позволяет вам больше контролировать, что происходит при доступе к данным (ленивая инициализация, нулевые проверки и т.д.).
Переменные являются частью реализации класса. Свойства более логично представляют собой интерфейс к нему. С С# 3.0 автоматически реализованные свойства делают это очень приятным с самого начала.
Я написал больше об этом, в том числе о различных способах перехода от переменной к свойству не только бинарной совместимости, но и совместимости источников, в статью по теме.
Приготовление. Вы никогда не знаете, когда вам захочется удалить установленный аксессуар по дороге, выполнить дополнительные операции в сеттере или изменить источник данных для get.
Публично доступные члены обычно должны быть методами, а не полями. Это просто хорошая практика, и эта практика помогает вам гарантировать, что инкапсулированное состояние ваших объектов всегда находится под вашим контролем.
Для инкапсуляции не рекомендуется использовать общедоступные поля.
http://my.safaribooksonline.com/9780321578815/ch05lev1sec5?displaygrbooks=0
Как сказал позже в этой книге Крис Андерсон, было бы идеально, если бы вызывающий был слеп к различию поля и свойства.
Чтобы сохранить высокую степень расширяемости без боли при повторной компиляции всех ваших сборок, вы хотите использовать общедоступные свойства в качестве аксессуаров. Следуя "контракту" или определенному механизму, который описывает, как ваши объекты будут обмениваться данными, будет установлен набор правил. Этот контракт применяется с интерфейсом и выполняется геттерами и сеттерами вашего класса, которые наследуют этот интерфейс.
Позже, если вы создадите дополнительные классы из этого интерфейса, у вас есть гибкость в соответствии с контрактом с использованием свойств, но поскольку вы предоставляете данные через геттеры и сеттеры, реализация или процесс сборки данных может все, что вы хотите, а также возвращает тип, который ожидает "контракт".