Частная переменная против свойства?

При установке значения переменной внутри класса большую часть времени мы представляем два варианта:

private string myValue;
public string MyValue
{
   get { return myValue; }
   set { myValue = value; }
}

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

Я бы сделал еще один шаг и довел это до 3 случаев. Хотя у каждого есть свои вариации, это правила, которые я использую большую часть времени при программировании на C #.

В случаях 2 и 3 всегда переходите к свойству свойства (а не к переменной поля). И в случае 1 вы избавлены от необходимости делать этот выбор.

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

public class Abc
{ 
  private readonly int foo;

  public Abc(int fooToUse){
    foo = fooToUse;
  }

  public int Foo { get{ return foo; } }
}

2.) Переменная POCO. Простая переменная, которую можно получить / установить в любой публичной / приватной области. В этом случае я бы просто использовал автоматическое свойство.

public class Abc
{ 
  public int Foo {get; set;}
}

3.) Свойства привязки ViewModel. Для классов, которые поддерживают INotifyPropertyChanged, я думаю, что вам нужна закрытая переменная вспомогательного поля.

public class Abc : INotifyPropertyChanged
{
  private int foo;

  public int Foo
  {
    get { return foo; }
    set { foo = value;  OnPropertyChanged("foo"); }
  }
}

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

Это, конечно, не фактор производительности. Оптимизатор встроит простое получение или установку для вас, и окончательный код MSIL, вероятно, будет идентичным.

Зависит.

Сначала вы должны предпочесть автоматические свойства, когда это возможно:

public string MyValue {get;set;}

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

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

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

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

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

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

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

Я всегда использую государственную собственность.

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

У вас есть комментарий о MVVM, который приводит к этому вопросу, и я чувствую, что это еще более важно при работе с MVVM. Многие объекты отправляют PropertyChangeуведомление установщику, а другие объекты могут подписаться на это событие, чтобы выполнить какое-либо действие при изменении определенных свойств. Если вы установите закрытую переменную, эти действия никогда не будут выполнены, если вы не вызовете PropertyChangedсобытие вручную .

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

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

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

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

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

public Foo Bar
{
  get { return _bar; }
  set { _bar = doSomethingTo(value); }
}

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

public Double SomeAngleDegrees
{
  get { return SomeAngleRadians * 180 / PI; }
  set { SomeAngleRadians = value * PI / 180; }
}

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

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