С новым подходом наличия get/set в атрибуте такого класса:
public string FirstName {
get; set;
}
Почему просто не просто поставить атрибут FirstName общедоступным без аксессуаров?
Две большие проблемы с прямым доступом к переменному внутреннему классу (поле/атрибут):
1) Вы не можете легко привязать данные к полям.
2) Если вы публикуете общедоступные поля из своих классов, вы не можете впоследствии изменить их на свойства (например: добавить логику проверки в сеттеры)
Потому что в будущем, если вы измените реализацию, код с использованием текущего интерфейса не сломается.
Например, вы реализуете простой класс с открытым полем и начинаете использовать свой класс в некоторых внешних модулях. Через месяц вы обнаружите, что вам нужно реализовать ленивую загрузку в этом классе. Затем вам нужно будет преобразовать поле в свойство. Из внешней точки модуля ciew он может выглядеть одинаково синтаксически, но это не так. Свойство - это набор функций, а поле - смещение в экземпляре класса.
Используя свойство, вы эффективно уменьшаете риск изменения интерфейса.
В основном это сводится к тому, что он стал общим соглашением о кодировании. Это облегчает добавление пользовательского кода обработки, если вы хотите. Но вы правы, технически нет реальной необходимости в этом. Хотя, если вы добавите пользовательскую обработку позже, это поможет вам не нарушать интерфейс.
Этот стиль нотации более полезен, когда вы смешиваете доступность для получателя и сеттера. Например, вы можете написать:
public int Foo { get; private set; }
Вы также можете установить внутренний сеттер или даже сделать доступным getter и setter публичным.
В этой нотации избегается явно писать личную переменную, чтобы справиться с классической проблемой внутреннего/доступного для чтения значения.
Ключ состоит в том, что компилятор переводит свойство "под капот" в пара функций, и когда у вас есть код, который выглядит так, как будто он использует свойство, он фактически вызывает функции при компиляции до IL.
Итак, скажем, вы создаете это как поле и имеете код в отдельной сборке, которая использует это поле. Если позже изменения в реализации и вы решите сделать это свойством, чтобы скрыть изменения от остальной части вашего кода, вам все равно необходимо повторно собрать и повторно развернуть другую сборку. Если это свойство с самого начала, все будет работать.
Я думаю, что спрашивающий спрашивает, почему бы не сделать следующее...
public string FirstName { }
Зачем беспокоиться об аксессуарах, когда вы могли бы укоротить его выше. Я думаю, что ответ заключается в том, что, требуя, чтобы аксессоры сделали очевидным для человека, читающего код, который является стандартным get/set. Без них вы можете видеть выше, это трудно заметить, это автоматически реализуется.
В 99% случаев публикация открытого поля прекрасна.
Общий совет - использовать поля: "Если вы публикуете публичные поля из своих классов, вы не сможете впоследствии изменить их на свойства". Я знаю, что все мы хотим, чтобы наш код был надежным, но есть некоторые проблемы с этим мышлением:
Потребители вашего класса могут, вероятно, перекомпилировать, когда вы измените свой интерфейс.
99% ваших данных никогда не будут нуждаться в нетривиальных свойствах. Это спекулятивная общность. Вы пишете много кода, который никогда не будет полезен.
Если вам нужна бинарная совместимость в разных версиях, сделать членов данных в свойствах, вероятно, недостаточно. По крайней мере, вы должны только разоблачать межфассу и скрывать все конструкторы и выставлять фабрики (см. Код ниже).
public class MyClass : IMyClass
{
public static IMyClass New(...)
{
return new MyClass(...);
}
}
Это сложная проблема, пытаясь сделать код, который будет работать в неопределенном будущем. Действительно трудно.
Есть ли у кого-нибудь пример времени при использовании тривиальных свойств, сохраненных их беконом?
Когда вы получаете ошибку, и вам нужно выяснить, какие методы изменяют ваши поля, и когда вам будет намного больше. Ввод легковесных аксессуаров для свойств вперёд спасает феноменальное количество сердечной боли, если возникает ошибка, связанная с заполненным полем. Я был в этой ситуации пару раз, и это не нравится, особенно когда это связано с повторным подключением.
Выполнение этой работы и фиксация точки останова на аксессуре намного проще, чем альтернативы.
Сохраняет инкапсуляцию объекта и упрощает чтение кода.