Там какое-либо преимущество к объявлению частной собственности с методом считывания и методом set?
Я рассматриваю код другого разработчика, и он написал много кода для переменных уровня класса, который подобен следующему:
/// <summary>
/// how often to check for messages
/// </summary>
private int CheckForMessagesMilliSeconds { get; set; }
/// <summary>
/// application path
/// </summary>
private string AppPath { get; set; }
Не кодирование этого пути добавляют ненужные издержки, так как переменная является частной?
Разве я не рассматриваю ситуации, где этот шаблон кодирования требуется для частных переменных?
8 ответов
Частные свойства предоставляют вам уровень абстракции, когда вы присваиваете значение частной переменной (которая создается для вас компилятором). Это не менее эффективно, и если в будущем вам понадобится изменить способ присвоения, вам придется беспокоиться о его обновлении только в одном месте.
Это также может обеспечить последовательность в приложении. Если все назначения выполняются через свойства, то одни могут проверять значения назначений, а другие - нет. Для человека, взаимодействующего со свойством, нет разницы между теми, которые проверяют, и теми, которые не проверяют. (и таким образом кто-то случайно не присвоит значение локальной переменной, которая не проверяется)
. Я бы сказал, что это хорошая практика иметь привычку использовать свойства вместо полей.
Накладные расходы, скорее всего, будут минимальными или отсутствуют, поскольку JIT может встроить геттер и сеттер. Таким образом, хотя это и не обязательно, нет ничего плохого в том, чтобы сделать это таким образом.
Я не вижу в этом реальной пользы, хотя и вреда не вижу. Если вы собираетесь в будущем превратить собственность в общедоступную, это может сэкономить вам немного времени на ввод. Но как часто вы конвертируете частные члены в общедоступную собственность? И когда вы это сделаете, это, вероятно, всего лишь один или два элемента из того, сколько членов ваш класс содержит. Если вы собираетесь преобразовать в нетривиальную реализацию или добавить какой-либо вид проверки, вам нужно будет преобразовать свойство автореализации в свойство с реальным резервным полем, что сводит на нет любое преимущество простоты, которое, как вы могли подумать, вы получили на Начните.
Мне это кажется личным предпочтением, не влияющим на производительность, и некоторым незначительным влиянием (как положительным, так и отрицательным) при внесении будущих изменений.
Это все равно что сказать, что частные методы бесполезны, поскольку они добавляют ненужные накладные расходы, и никто вне класса не будет их использовать.
Свойства дают вам одну точку соприкосновения между переменной и остальной частью вашего кода. В будущем вы можете захотеть добавить проверку ошибок или обновлять какое-либо другое значение при изменении переменной, и свойства позволят вам это сделать.
Нет, jit-компилятор преобразует доступ к свойствам в прямой доступ к переменной в поле поддержки, поэтому он не менее эффективен, чем использование переменной-члена напрямую.
Преимущество состоит в том, что если вы когда-либо захотите преобразовать свойство в нетривиальную реализацию, вы можете просто добавить код в get / set, чтобы разрешить дополнительные проверки или поведение или другой механизм хранения, который будет использоваться для свойства без необходимости рефакторинг любого клиентского кода (в данном случае все в одном классе).
перейдите по этой ссылке:
Они обсуждают один и тот же вопрос.
HTH
Проблема производительности, вероятно, незначительна или вообще не существует, но это требует от вас ввода еще 9 символов (+ пробелы) без какого-либо выигрыша. Если вы позже захотите преобразовать поля в свойства, вы сможете сделать это в любом случае, поскольку поля и свойства полностью совместимы с исходным кодом (при условии, что вы не используете изменяемые типы значений).
IIRC, компилятор оптимизирует доступ к свойствам, и в конечном итоге они будут прямыми ссылками на автоматически сгенерированное резервное поле.
Это не приведет к лишним накладным расходам, сделает код более чистым и удобным в обслуживании.