Do private classes need to be accessed by properties?

Question

I am using an instance of a private class as the state object supplied to a stream.BeginRead operation. (The class is private to my main stream reading/writing class.)

public class MainClass
{
    // ...

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

Access to the class is via the fields directly. Should I really be providing access to the class via properties in this case, even though it is only to be used for holding state?

Interested to know what others do.

Answer 1

It's not required by the C# language, but it is good practice never to expose a field directly for maintainability reasons - it is suggested to use a property instead.

See StyleCop SA1401: FieldsMustBePrivate.

TypeName - FieldsMustBePrivate
CheckId - SA1401
Category - Maintainability Rules

Cause

A field within a C# class has an access modifier other than private.

Rule Description

A violation of this rule occurs whenever a field in a class is given non-private access. For maintainability reasons, properties should always be used as the mechanism for exposing fields outside of a class, and fields should always be declared with private access. This allows the internal implementation of the property to change over time without changing the interface of the class.

Fields located within C# structs are allowed to have any access level.

How to Fix Violations

To fix a violation of this rule, make the field private and add a property to expose the field outside of the class.

If your class is purely state for the containing class then you could consider placing the members directly inside the class that uses them. If your class is more than just state (and I suspect it is) then it should follow the usual maintainability rules.

Answer 2

I would - encapsulation is useful inside the class as well as outside the class. By funneling all access to a member through a well know interface (i.e. the property) you are giving yourself the flexibility to add logic around that access later without changing calling code.

It may seem like overkill but honestly, given automatically implemented properties, it is so easy to declare a property that you may as well go ahead and use one to give yourself maximum flexibility.

Answer 3

In my organization, when a class was private or internal, and it's a entity class, we used public fields to access it.

However, since C# 3.0 we use automatic properties, so we always use properties to access private fields.

Anyway, the effect is the same, in our case it was to do the code more readable.

Answer 4

Best practice is to use properties for every member accessible by other types. Automatic properties at C# 3.0 makes this quite easy.

Answer 5

I have just done some reading on this a week or two ago. There are the two camps. One the majority say you must wrap in the property because my teacher said so and everyone else does it. They say that is easier to add extra logic to a property or more maintainable and some other weak reasons. The other camp, call themselves "the true OO guys" tend to be along the line of if you use properties at all you are doing it wrong (with some exceptions of course). Your case would be the exception as far as I can tell. Actually, thinking about it, they would probably still say you are doing it wrong :) Just cant win. Anyway, they also say if you are going to use them don't bother wrapping unless you need the extra logic in your setters and getters. Why slow your program down for nothing. (apparently they can measure how slow too).

I tend to use properties over fields as I do a lot of MVVM and need to implement INotifyPropertyChanged which requires them. In your case I wouldn't worry about wrapping them in properties just makes for pointless fat. But if it was in a class that needed a property then I would wrap them to keep things similar in that class.

If after all that you didn't wrap them, and needed to later, it's a right click refactor->encapsulate field to wrap a property if you have Resharper.