Есть ли причины использовать частные свойства в C #?

Question

Я только что понял, что конструкцию свойства C # можно также использовать с модификатором доступа private :

private string Password { get; set; }

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

private string _password;

и я не могу себе представить, когда мне когда-нибудь понадобится внутренне получить , но не установить или установить но не получить личное поле:

private string Password { get; }

или

private string Password { set; }

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

Кто-нибудь использует частные свойства в C # по какой-либо причине, или это только одна из тех технически возможных, но редко используемых в фактическом коде конструкций?

Добавление

Хорошие ответы, прочитав их, я выбрал следующие варианты использования частных объектов:

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

Answer 1

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

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

Answer 2

Это имеет смысл, когда есть логика, связанная со свойством set или get (подумайте, ленивая инициализация), и свойство используется в нескольких местах в классе.

Если это просто прямое поле поддержки?Ничто не приходит на ум в качестве веской причины.

Answer 3

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

Answer 4

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

• Проверка

  string _password;
  string Password
  {
      get { return _password; }
      set
      {
          // Validation logic.
          if (value.Length < 8)
          {
              throw new Exception("Password too short!");
          }
  
          _password = value;
      }
  }
  

• Замок

  object _lock = new object();
  object _lockedReference;
  object LockedReference
  { 
      get
      {
          lock (_lock)
          {
              return _lockedReference;
          }
      }
      set
      {
          lock (_lock)
          {
              _lockedReference = value;
          }
      }
  }
  

  Примечание. При блокировке ссылки вы не блокируете доступ к элементам ссылочного объекта.

Ленивая ссылка: При отложенной загрузке вам может потребоваться сделать это асинхронно, для которой в настоящее время существует AsyncLazy . Если вы используете более старую версию Visual Studio SDK 2015 или не используете ее, вы также можете использовать AsyncLazy AsyncEx .

Answer 5

Некоторые более экзотические варианты использования явных полей включают:

• , вам необходимо использовать ref или out со значением - возможно, потому что это Interlocked counter
• он предназначен для представления фундаментального макета, например, на struct с явным макетом (возможно, для сопоставления с дампом C ++ или unsafe кодом)
• исторически типиспользуется с BinaryFormatter с автоматической обработкой полей (изменение на auto-props изменяет имена и, таким образом, разрушает сериализатор)

Answer 6

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

Я не могу себе представить, когда мне когда-нибудь понадобится иметь возможность получить внутренне, но не установить

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

Кроме того, Visual Studio Professional будет предоставлять информацию о свойстве, а не поле, чтобы было легче увидеть, какое поле используется.