Подтвердить что ты не робот

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

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

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

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

Не кодирует ли этот способ лишние служебные данные, поскольку переменная является частной?

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

Ответ 3

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

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

Ответ 4

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

Ответ 5

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

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

Ответ 7

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

Ответ 8

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

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