Правильное использование свойств C #

Лично я предпочитаю первый метод, так как он позволяет выполнить несколько операций до возврата.

Э. (Очень плохой пример)

    private int _limit;
    private int _onHand;
    private bool returnToVendor;

    public Item(int limit, int onHand)
    {
       _limit = limit;
       _onHand = onHand;
    }

    public int ReturnStock
    {
       get
       {
         if(_onHand > _limit)
         {
            returnToVendor = true;
            return _onHand;
         }
       }

       set
       {
           _onHand = value;

           if(_onHand < _limit)
           {
              returnToVendor = false;
           }
       }
    }

Пока вам не нужно удостовериться, что List инициализирован в геттере, вас устраивают обе версии. Я просто предлагаю вам использовать одну версию и не смешивать ее в своем коде ...

Если вам нужна ее инициализация, вам нужно перейти к первой версии ...

private List<Date> _dates; 

public List<Date> Dates 
{ 
    get { if (_dates == null) _dates = new List<Date>(); return _dates; } 
    set { _dates = value; } 
} 

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

Эти два компонента компилируются примерно одинаково (я не знаю, будет ли имя вспомогательного поля точно таким же, но они будут функционально эквивалентны).

IIRC, возможность делать автоматические свойства ( public List Dates {get; set;} ) была добавлена ​​либо в .NET 3.0, либо в 3.5.

Оба в основном одинаковы из-за того, как .NET компилирует автоматические свойства. Автоматические свойства стали доступны в .NET 3.5.

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

Некоторые люди (в том числе и я) сторонятся автоматических свойств, потому что синтаксис легко перепутать с абстрактными свойствами, нет возможности для свойств 'readonly' и синтаксис для автоматических свойств с приватными сеттерами неуклюж:

public List Dates
{
    get;
    private set;
}

Я также считаю неудобным, когда внутренняя реализация моих классов получает доступ к полям через API класса.

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

Почти все мои объявления свойств выглядят так:

public bool IsBlah { get; private set; }

Это делает его красивым, читаемым и защищенным геттером.

Но бывают случаи, когда вам нужно явное защитное поле:

private bool? _isBlah;
public bool IsBlah
{
    get
    {
        if (_isBlah == null)
        {
            // Do something expensive here and set _isBlah
            _isBlah = true;
        }
        return _isBlah;
    }
}

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

private IList<DateTime> _dates;

public MyClass() {
    _dates = new List<DateTime>();
}

public IList<DateTime> Dates {
    get {
        return _dates;
    }
}

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

Однако в вашем примере вам нужно использовать только первый подход, если вам нужна какая-то логика при получении или установке свойства. В противном случае автоматические свойства делают то же самое, что и вы, только получают и устанавливают значение для частного поля. Кроме того, {get; набор; } улучшает читаемость и помогает другим программистам понять ваши намерения, с моей скромной точки зрения.

Например:

public class MyClass {
    private IList<DateTime> _dates;

    public IList<DateTime> Dates {
        get {
            return _dates;
        } set {
            _dates = value;
        } 
    }
}

против

public class MyClasse {
    public IList<DateTime> Dates { get; set; }
}

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

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

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

Второй вариант, известный как автоматически реализуемые свойства , был представлен в C # 3.0 (поэтому вы, возможно, не встречали его раньше).

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

Обратите внимание, что вы все еще можете инициализировать свойства, вы просто делаете это через конструктор.

public class MyClass
{

  public List<Date> Dates
  {
      get;        
      set;    
  }

  public MyClass()
  {
      Dates = new List<Date>();
  }

}

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

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

В противном случае используйте последний вариант. Это делает вещи намного чище. Вы также можете получить свойства только для чтения, используя автоматические свойства:

public List<Date> Dates { get; private set; }

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

private List<Date> _dates = new List<Date>();
private ReadOnlyCollection<Date> _readOnlyDates =
    new ReadOnlyCollection<Date>(_dates);

public ReadOnlyCollection<Date> Dates
{
    get { return _readOnlyDates; }
}