Should you use Fields or just Properties in C#?

Question

I've seen some people who make properties for every single member, private or not... does this make any sense?

private string mWhatever;

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = value;
    }
}

I could see it making sense in 1% of the cases at times when you want to control access to the member inside the class containing it.
Because if you don't use properties for every member it would lead to inconsistencies and checking to see if the member has an access or not (since you have access to both in the scope of the class).

Answer 1

Short answer: Yes, when there is a need. Otherwise, use an Auto-Implemented Property getter and setter like private string Whatever { get; set;}

• It is very handy When you are using a close domain approach
• It is also handy when a specific logic should be checked when you are setting the value

Here is a full description of when you would be using private setters: C# property usage.

Answer 2

Some good answers here already, but I think most of them miss one point of your question:

I've seen some people who make properties for every single member, private or not... does this make any sense?

I think this is seldom necessary beforehand, for every single member. Start with

 private string Whatever;

When you later come to a point where you need encapsulation or a conditional breakpoint for this specific member, you can still replace it by a property with same name - in most cases without changing the code which uses Whatever. But beware, there are subtle differences, see Brian Rasmussen's answer in this SO post (link also given by Emmad Kareem, +1).

Answer 3

One of the biggest advantages of this approach is that you get control on when your variables change.

Consider the following.
You are debugging a large project. A certain method throws an exception. You set a breakpoint and you reveal that a certain member variable has wrong value. Say your code relies on this variable very extensively, and you find hundreds write usages (Spaghetti scenario). So you can't figure out which of these usages assigned a bad value.
If the code is multithreaded, debugging may become a real nightmare.

With property, you may set a breakpoint in a setter. Combined with a condition, it may be nailed down in a single run.

VC++ has data breakpoints, but it is only available for unmanaged code.

Answer 4

Private properties can be very useful to encapsulate the behaviour of things which are internal to your class. Just because they are private doesn't mean that you shouldn't take advantage of the syntactic sugar that properties give you.

---

The example given is a poor one, however. Boilerplate property getters and setters like this are almost always a bad idea. If you are using C# 3.0 or later then, auto properties are a much better idea:

private string Whatever { get; set; };

This is shorter, cleaner, and much more readable. In fact it is barely longer than just declaring the backing variable.

Most importantly though, auto properties can be converted to full properties at any time without changing the semantics of the rest of the program! Thus if you need to add validation or error handling, you can do so easily.

---

As it is, I always thought it was a shame that you couldn't have a read only property, to enforce only being able to write to the value in the constructor, (I prefer immutable types) but this was added in C# 6.0 as "Auto-Property Initializers", which allows you to do:

private string Whatever { get; } = ...;

or

private string Whatever { get; };

along with

    Whatever = ...;

in the constructor.

Answer 5

If you don't use a property, your only other option is to use a field to store variable data. Properties and fields have significant differences. Most of these differences are found Fields vs. Properties. I suggest you study the differences then make your choice according to your application needs. However, bear in mind that using fields instead of properties is not the common OO practice because of their nature and shortcoming.

Answer 6

Yeah

I personally use this as the caching mechanism, and we might call it property-level caching.

private List<User> users;
private List<User> Users
{
    get
    {
        if(users == null) users = new UserManager().GetUsers();
        return users;
    }
}

Now in other places inside my class, I use Users property instead of users field.

Another feasible situation might be when you want to implement some logic on a field, but in a centralized way in a class. Thus you can both create a GetFoo() method, or a Foo property for foo field.

private string foo;
private string Foo
{
    get
    {
        return "Mr. " + foo;
    }
}

Answer 7

It's not absolutely necessary to do this for private properties, but it does allow for modifying how the property gets/sets the underlying value without changing how it is accessed.

For example, modifying how the underlying value is set:

private string Whatever
{
    get
    {
        return this.mWhatever;
    }
    set
    {
        this.mWhatever = string.IsNullOrEmpty(value) ? string.Empty : value;
    }
}

Answer 8

Something else to consider:

Actual properties are an implementation detail. One of the goals of OOP is to try and minimize the exposure of implementation details where practical.

The reason for this is if you hide the properties and only expose them through getters and setters, you have far more control. For example, your getter can validate its input and prevent the property being set to an invalid state. If the ability to change the value is time critical, then the setter can protect against this too. The getter, should getting the actual value be expensive for whatever reason, can do lazy initialization and/or caching.

Having getters and setters exposed and the properties hidden means sometimes you don't need a property at all. Your getter can compute the value on invocation, or delegate the task somewhere else, or anything that lets it meet its specification. What's important about your class is the information you can access from it, not how that information is represented internally.

Of course, if there's no negative consequences to anything outside the class being able to access a property directly, then you should just make it public. However in my experience, such cases are relatively few and far between.

Answer 9

I know this is an old question and everything @Yusubov said is correct, but with respect to his second bullet point about specific logic in the setter, and since I didn't see anyone specifically mention this, a perfect example would be when your class implements the INotifyPropertyChanged interface.

This is used a ton in WCF and Silverlight which allows you to know when a specific property has changed via the logic in its setter like in the class below:

public class Settings : INotifyPropertyChanged
{
    public Settings() 
    { 
        this.CountryField = String.Empty; 
    }

    private string CountryField;
    public string Country
    {
        get { return this.CountryField; }
        set
        {
            if (Object.ReferenceEquals(this.CountryField, value)) { return; }

            this.CountryField = value;
            this.RaisePropertyChanged("Country");
        } 
    }

    public event PropertyChangedEventHandler PropertyChanged;
    private void RaisePropertyChanged(string propertyName)
    {
        PropertyChangedEventHandler propertyChanged = this.PropertyChanged;

        if (propertyChanged != null)
            propertyChanged(this, new PropertyChangedEventArgs(propertyName));
    }
}