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

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

private string Password { get; set; }

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

private string _password;

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

private string Password { get; }

или

private string Password { set; }

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

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

добавление

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

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

c#,properties,access-modifiers,

180

Ответов: 14


160 ов принято

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

private string _password;
private string Password
{
    get
    {
        if (_password == null)
        {
            _password = CallExpensiveOperation();
        }

        return _password;
    }
}

103

Основное использование этого в моем коде - это ленивая инициализация, как упомянули другие.

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

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


35

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

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

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


В полузависимом случае (хотя и отличается от вашего вопроса), я очень часто использую частные сеттеры для публичных объектов:

public string Password 
{
    get; 
    private set;
}

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


19 ов

Ленивая инициализация - это одно место, где они могут быть аккуратными, например

private Lazy<MyType> mytype = new Lazy<MyType>(/* expensive factory function */);

private MyType MyType { get { return this.mytype.Value; } }

// In C#6, you replace the last line with: private MyType MyType => myType.Value;

Тогда вы можете написать: this.MyTypeвезде, а не this.mytype.Valueи инкапсулировать тот факт, что он лениво создается в одном месте.

Одно дело, что стыдно, что C # не поддерживает определение области поддержки для свойства (т. Е. Объявление его внутри определения свойства), чтобы полностью скрыть его и обеспечить доступ к нему только через свойство.


15

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

C #, свойства, модификаторы доступа,
Похожие вопросы