С# 3.0 Автоматические свойства, почему бы не получить доступ к полю напрямую?

Ответ 1

Две большие проблемы с прямым доступом к переменному внутреннему классу (поле/атрибут):

1) Вы не можете легко привязать данные к полям.

2) Если вы публикуете общедоступные поля из своих классов, вы не можете впоследствии изменить их на свойства (например: добавить логику проверки в сеттеры)

Ответ 2

Потому что в будущем, если вы измените реализацию, код с использованием текущего интерфейса не сломается.

Например, вы реализуете простой класс с открытым полем и начинаете использовать свой класс в некоторых внешних модулях. Через месяц вы обнаружите, что вам нужно реализовать ленивую загрузку в этом классе. Затем вам нужно будет преобразовать поле в свойство. Из внешней точки модуля ciew он может выглядеть одинаково синтаксически, но это не так. Свойство - это набор функций, а поле - смещение в экземпляре класса.

Используя свойство, вы эффективно уменьшаете риск изменения интерфейса.

Ответ 3

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

Ответ 4

Этот стиль нотации более полезен, когда вы смешиваете доступность для получателя и сеттера. Например, вы можете написать:

public int Foo { get; private set; }

Вы также можете установить внутренний сеттер или даже сделать доступным getter и setter публичным.

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

Ответ 5

Ключ состоит в том, что компилятор переводит свойство "под капот" в пара функций, и когда у вас есть код, который выглядит так, как будто он использует свойство, он фактически вызывает функции при компиляции до IL.

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

Ответ 6

Я думаю, что спрашивающий спрашивает, почему бы не сделать следующее...

public string FirstName { }

Зачем беспокоиться об аксессуарах, когда вы могли бы укоротить его выше. Я думаю, что ответ заключается в том, что, требуя, чтобы аксессоры сделали очевидным для человека, читающего код, который является стандартным get/set. Без них вы можете видеть выше, это трудно заметить, это автоматически реализуется.

Ответ 7

В 99% случаев публикация открытого поля прекрасна.

Общий совет - использовать поля: "Если вы публикуете публичные поля из своих классов, вы не сможете впоследствии изменить их на свойства". Я знаю, что все мы хотим, чтобы наш код был надежным, но есть некоторые проблемы с этим мышлением:

• Потребители вашего класса могут, вероятно, перекомпилировать, когда вы измените свой интерфейс.

• 99% ваших данных никогда не будут нуждаться в нетривиальных свойствах. Это спекулятивная общность. Вы пишете много кода, который никогда не будет полезен.

• Если вам нужна бинарная совместимость в разных версиях, сделать членов данных в свойствах, вероятно, недостаточно. По крайней мере, вы должны только разоблачать межфассу и скрывать все конструкторы и выставлять фабрики (см. Код ниже).

public class MyClass : IMyClass
{
    public static IMyClass New(...)
    {
        return new MyClass(...);
    }
}

Это сложная проблема, пытаясь сделать код, который будет работать в неопределенном будущем. Действительно трудно.

Есть ли у кого-нибудь пример времени при использовании тривиальных свойств, сохраненных их беконом?

Ответ 8

Когда вы получаете ошибку, и вам нужно выяснить, какие методы изменяют ваши поля, и когда вам будет намного больше. Ввод легковесных аксессуаров для свойств вперёд спасает феноменальное количество сердечной боли, если возникает ошибка, связанная с заполненным полем. Я был в этой ситуации пару раз, и это не нравится, особенно когда это связано с повторным подключением.

Выполнение этой работы и фиксация точки останова на аксессуре намного проще, чем альтернативы.

Ответ 9

Сохраняет инкапсуляцию объекта и упрощает чтение кода.