Should I use public properties and private fields

Question

In much of the code I have seen (on SO, thecodeproject.com and I tend to do this in my own code), I have seen public properties being created for every single private field that a class contains, even if they are the most basic type of get; set; like:

private int myInt;
public int MyInt 
{
     get { return myInt; }
     set { myInt = value }
}

My question is: how does this differ from:

public int MyInt;

and if we should use properties instead of public fields why should we use them in this specific case? (I am not talking about more complex examples where the getters and setters actually do something special or there is only one get or set (read/write only) rather than just returning/setting a value of a private field). It does not seem to add any extra encapsulation, only give a nice icon in IntelliSense and be placed in a special section in class diagrams!

Answer 1

I can't believe that with 11 answers, nobody has said this:

Not all private fields should be exposed as public properties. You should certainly use properties for anything that needs to be non-private, but you should keep as much of your class private as possible.

Answer 2

You have to use properties in the following cases:

1. When you need to serialize data in the property to some format.
2. When you need to override properties in derived class.
3. When you implement get and set methods with some logic. For example, when you implement Singleton pattern.
4. When you're derived from interface, where property was declared.
5. When you have specific issues related to Reflection.

Answer 3

In simpler words, answer to your question is the access modifiers i.e. public and private.

If you use:

public int myInt;
public int MyInt 
{
     get { return myInt; }
     set { myInt = value }
}

then both MyInt property and myInt variable is available in the project to be modified. Means, if your class suppose A is inherited by class suppose B, then myInt and MyInt both are available for modification and no check can be applied. Suppose you want myInt value can be set in derive class if some particular condition pass.

This can be achieved only by making field private and property to be public. So that only property is available and conditions can be set based on that.

Answer 4

Well it does make a difference. Public data can be changed without the object instance knowing about it. Using getters and setters the object is always aware that a change has been made.

Remember that encapsulating the data is only the first step towards a better structured design, it's not an end-goal in itself.

Answer 5

The idea is you should not accidentally/unintentionally change the value of a class private field outside. When you use get and set, that means you are changing the class private field intentionally and knowingly.

Answer 6

Three reasons:

1. You cannot override fields in subclasses like you can properties.
2. You may eventually need a more complex getter or setter, but if it's a field, changing it would break the API.
3. Convention. That's just the way it's done.

I'm sure there are more reasons that I'm just not thinking of.

In .Net 3.x you can use automatic properties like this:

public int Age { get; set; }

instead of the old school way with declaring your private fields yourself like this:

private int age;

public int Age
{
    get { return age; }
    set { age = value; }
}

This makes it as simple as creating a field, but without the breaking change issue (among other things).