При установке значения переменной внутри класса большую часть времени мы представляем два варианта:
private string myValue;
public string MyValue
{
get { return myValue; }
set { myValue = value; }
}
Существует ли соглашение, которое определяет, как мы должны присваивать значения переменным внутри наших классов? Например, если у меня есть метод внутри того же класса, я должен назначить его с помощью свойства или с помощью закрытой переменной. Я видел, как это происходит в обоих направлениях, поэтому мне было интересно, если это выбор или производительность является фактором (незначительным, вероятно).
источник
public int Foo {get; set;}
вместоpublic int Foo
?Как правило, я бы сказал, присваивать поле в конструкторе и использовать свойство везде. Таким образом, если кто-то добавляет функциональность к свойству, вы его нигде не пропустите.
Это, конечно, не фактор производительности. Оптимизатор встроит простое получение или установку для вас, и окончательный код MSIL, вероятно, будет идентичным.
источник
Зависит.
Сначала вы должны предпочесть автоматические свойства, когда это возможно:
Во-вторых, лучшим подходом, вероятно, было бы использование свойств, если у вас есть какая-то логика, вы, вероятно, должны проходить через нее самостоятельно, особенно если эта логика - синхронизация потоков.
Но вы также должны принять во внимание, что это может снизить вашу производительность (немного), если вы неправильно синхронизируете, вы можете заблокировать себя, и иногда правильный путь - обойти логику в свойстве.
источник
public string MyValue {get; private set;}
.Что ж, прямой подход заключается в том, чтобы просто присвоить его самой переменной, так как вы находитесь внутри метода класса и в любом случае управляете поведением класса.
Но суть свойств в том, что они абстрагируют переменную. В то время как такое простое свойство, как в вашем примере, совершенно бесполезно по сравнению с простой общедоступной переменной-членом, свойства обычно делают (или должны делать) дополнительные вещи внутри своих методов получения и установки. И если вы хотите, чтобы эти вещи выполнялись автоматически при изменении свойства внутри класса, тогда, конечно, лучше работать со свойством, а не с переменной, чтобы не приходилось изменять каждое назначение переменной при изменении поведения установки свойства.
Вы просто должны рассуждать об этом концептуально. Свойство фактически является дескриптором для доступа к некоторому внутреннему состоянию объекта, которое может состоять из нескольких переменных-членов. Поэтому вы должны спросить себя, хотите ли вы изменить только базовое внутреннее состояние (или только его часть) или абстрактное свойство, представляющее это состояние в целом, и в большинстве случаев это действительно последнее, поскольку вы обычно хотите, чтобы ваш объект всегда имел последовательное состояние.
источник
Если есть вероятность, что реализация этих свойств get / set будет иногда меняться позже (например, вы хотите вызвать событие при вызове
set
или позже добавите некоторый ленивый механизм оценки в своюget
функцию), тогда это может быть хорошей идеей что ваш код внутри класса будет использовать это свойство почти во всех случаях, за исключением - наиболее вероятно, редких - случаев, когда вы явно не хотите, чтобы эти события или ленивые механизмы оценки использовались.В любом случае, что бы вы ни делали, есть хороший шанс, что когда вы позже измените реализацию свойства таким образом, вам придется посмотреть на все места внутри вашего класса, которые обращаются к этому свойству, чтобы проверить, действительно ли к этому свойству нужно обращаться или должна использоваться закрытая переменная
источник
Я всегда использую государственную собственность.
Часто некоторая логика, которая всегда должна выполняться при установке свойства, добавляется к
set
методу свойства, и вместо установки открытого поля общедоступный установщик обходит любую логику.У вас есть комментарий о MVVM, который приводит к этому вопросу, и я чувствую, что это еще более важно при работе с MVVM. Многие объекты отправляют
PropertyChange
уведомление установщику, а другие объекты могут подписаться на это событие, чтобы выполнить какое-либо действие при изменении определенных свойств. Если вы установите закрытую переменную, эти действия никогда не будут выполнены, если вы не вызоветеPropertyChanged
событие вручную .источник
Как правило, это зависит от вас, что вы должны делать со свойством и его вспомогательным полем при получении / установке.
Чаще всего, чтобы быть единообразным в коде, вы должны использовать общедоступные средства доступа везде, где они доступны и уместны. Это позволяет вам проводить рефакторинг с минимальным изменением кода; если метод, выполняющий этот параметр, должен быть удален из класса и помещен в другое место, где вспомогательное поле больше не доступно (например, базовый класс), кого это волнует? Вы используете то, что доступно везде, где сам класс выполняет свою работу. Основное поле, в большинстве случаев, является деталью реализации; никто за пределами вашего класса не должен знать, что он существует.
Основная ситуация, о которой я могу думать, когда вам следует использовать поле поддержки, а НЕ средство доступа к свойству, - это когда средство доступа имеет дополнительную логику (проверку или обновление другой информации о состоянии в классе), которую вы не хотите запускать. Начальная популяция объекта является примером; у вас может быть класс, который использует два значения свойства для вычисления третьего значения, которое также хранится в резервном поле (по соображениям постоянства). При инициализации новой копии этого объекта с данными из БД, средства доступа к свойствам, каждое из которых пересчитывает третье значение, могут жаловаться, если другое необходимое значение не установлено. Используя вспомогательные поля для установки начальных значений этих двух (или трех) свойств, вы обходите логику проверки / вычисления до тех пор, пока экземпляр не окажется в достаточно согласованном состоянии для нормальной работы логики.
источник
Всегда используйте тот, который имеет смысл. Да, я знаю, что это звучит довольно фальшиво до такой степени, что я не отвечаю.
Смысл свойств заключается в предоставлении интерфейса, через который вы можете безопасно получить доступ к модели данных. В большинстве случаев вам всегда нужен безопасный доступ к модели данных через этот интерфейс, например:
Но в других ситуациях вы можете просто использовать свойство как представление модели данных:
Если имеет смысл использовать форму в радианах
SomeAngle
, то обязательно используйте ее.В конце концов, обязательно выпейте свою собственную помощь kool. Ваш публичный API должен быть достаточно устойчивым, чтобы работать внутри.
источник