Есть ли какая-либо польза от объявления частной собственности с установщиком и установщиком?

Question

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

    /// <summary>
    /// how often to check for messages
    /// </summary>
    private int CheckForMessagesMilliSeconds { get; set; }

    /// <summary>
    /// application path
    /// </summary>
    private string AppPath { get; set; }

Разве кодирование не добавляет ненужных накладных расходов, поскольку переменная является приватной?

Не рассматриваю ли я ситуацию, когда этот шаблон кодирования требуется для частных переменных?

Answer 1

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

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

Answer 2

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

Может также обеспечить согласованность в приложении. Если все назначения выполняются через свойства, то некоторые могут проверять значения назначений, а другие нет. Для человека, взаимодействующего с собственностью, нет разницы между теми, кто проверяет, и теми, которые не проверяют. (и таким образом кто-то случайно не присваивает значение локальной переменной, которая не проверяется.)

Answer 3

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

Answer 4

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

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

Answer 5

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

Это приведет к отсутствию накладных расходов, более чистому и более понятному коду.

Answer 6

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

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

Answer 7

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

Answer 8

проверить эту ссылку:

http://social.msdn.microsoft.com/Forums/en-US/csharplanguage/thread/3f580715-9d84-4468-92a1-7cf4831aa3f6

Они обсуждают одну и ту же проблему.

НТН