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

можно писать

public string Forename{ get; private set; }

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

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

в первом случае компилятор автоматически добавит поле для вас, и оберните собственность. Это в основном эквивалентно doing:

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

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

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

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

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

рассмотрим некоторые связанные темы о разница между автоматическими свойствами и открытыми полями, поля против свойства, автоматические свойства-полезно или нет?, почему бы не использовать Public Fields.

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

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

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;
   }
}

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

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

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

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

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

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

свойство похоже на контракт, и вы можете изменить имплементацию свойства, не затрагивая клиентов, использующих ваши классы и свойства. Сегодня у вас может не быть никакой логики, но по мере изменения бизнес-требований и если вы хотите ввести какой-либо код, свойства-ваша самая безопасная ставка. Следующие 2 ссылки-отличные видеоуроки c# . Первый объясняет необходимость свойств только с помощью полей, а второе видео объясняет различные типы свойств. Я нашел их очень полезно.

потребность в свойствах в C#

Poperties в C#, только для чтения, только для записи, чтение / запись, авто реализовано

взгляните на следующий код и объяснение.
The most common implementation for a property is getter or a setter that simply reads and writes to a private field of the same type as a property. An automatic property declaration instructs the compiler to provide this implementation. The compiler automatically generates a private backing field.
Посмотрите на следующий код:-

    public class Stock 
    {
      decimal currentPrice ;  // private backing field.
      public decimal CurrentPrice 
      {
        get { return currentPrice ; }
        set { currentPrice = value ; }
      }
   }

тот же код можно переписать как : -

   public class Stock
   {
     public decimal CurrentPrice { get ; set ; } // The compiler will auto generate a backing field.
   }

источник:- C# в двух словах