C# автоматические свойства

Вы можете написать

public string Forename{ get; private set; }

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

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

В первом случае компилятор будет автоматически добавит поле для вас и обернет свойство. По сути, это эквивалентно выполнению:

private string forename;
public string Forename
{
    get
    { 
        return this.forename;
    }
    set
    {
        this.forename = value;
    }
}

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

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

Это означает, что вы ожидаете добавить логику позже.

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

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

Публичные члены данных - зло (в том смысле, что объект не контролирует модификацию своего собственного состояния - он становится глобальной переменной). Нарушение инкапсуляции - принцип ООП.

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

public string ID { get; set;}

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

string m_ID;
public string ID
{
   get { return m_ID; }
   set 
   { 
     //validate value conforms to a certain pattern via a regex match
     m_ID = value;
   }
}

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

Рассмотрите возможность просмотра некоторых связанных тем о Различии между автоматическими свойствами и общедоступными полями , Поля и свойства , Автоматические свойства - полезны или нет ? , Почему бы не использовать общедоступные поля .

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

Если вы перешли от общедоступной переменной к свойству, это было бы критическим изменением для других библиотек, которые ссылаются на вашу - следовательно, почему бы не начать с свойства auto? :)

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

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