Должны ли частные классы обращаться к свойствам?

Question

Я использую экземпляр закрытого класса в качестве объекта состояния, предоставленного операции stream.BeginRead. (Этот класс является приватным для моего класса чтения / записи основного потока.)

public class MainClass
{
    // ...

    private class ResponseState
    {
        public IResponse response;
        public Stream stream;
        public byte[] buffer = new byte[1024];
    }
}

Доступ к классу осуществляется через поля напрямую. Должен ли я действительно предоставлять доступ к классу через свойства в этом случае, даже если он используется только для хранения состояния?

Интересно узнать, что делают другие.

Answer 1

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

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

Answer 2

Это не требуется языком C#, но рекомендуется никогда не выставлять поле напрямую для удобства сопровождения - вместо этого предлагается использовать свойство.

См. StyleCop SA1401: FieldsMustBePrivate.

TypeName - FieldsMustBePrivate
CheckId - SA1401
Категория - Правила сопровождения

причина

Поле в классе C# имеет модификатор доступа, отличный от private.

Описание правила

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

Поля, расположенные в структурах C#, могут иметь любой уровень доступа.

Как исправить нарушения

Чтобы исправить нарушение этого правила, сделайте поле приватным и добавьте свойство, чтобы выставить поле за пределами класса.

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

Answer 3

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

Однако, начиная с C# 3.0, мы используем автоматические свойства, поэтому мы всегда используем свойства для доступа к закрытым полям.

В любом случае, эффект тот же, в нашем случае это сделать код более читабельным.

Answer 4

Рекомендуется использовать свойства для каждого члена, доступного для других типов. Автоматические свойства в C# 3.0 делают это довольно легко.

Answer 5

Я только что прочитал об этом неделю или две назад. Есть два лагеря. Один из них говорит, что вы должны обернуть помещение, потому что так сказал мой учитель, и все остальные делают это. Они говорят, что легче добавить дополнительную логику к свойству или более легкую в обслуживании и некоторые другие слабые причины. Другой лагерь, называющий себя "настоящими ОО-парнями", склонен идти по пути того, что если вы вообще используете свойства, вы делаете это неправильно (за некоторыми исключениями, конечно). Насколько я могу судить, ваш случай был бы исключением. На самом деле, думая об этом, они, вероятно, по-прежнему говорят, что вы делаете это неправильно:) Просто не могу победить. В любом случае, они также говорят, что если вы собираетесь их использовать, не беспокойтесь об упаковке, если вам не нужна дополнительная логика в ваших установщиках и получателях. Зачем тормозить вашу программу ни за что. (по-видимому, они могут измерить, насколько медленно).

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

Если после всего этого вы не обернули их, а вам нужно было позже, щелкните правой кнопкой мыши поле refactor->encapsulate, чтобы обернуть свойство, если у вас есть Resharper.