Should I use public properties and private fields or public fields for data?

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!

Solution 1

See this article http://blog.codinghorror.com/properties-vs-public-variables/

Specifically

• Reflection works differently on variables vs. properties, so if you rely on reflection, it's easier to use all properties.
• You can't databind against a variable.
• Changing a variable to a property is a breaking change.

Solution 2

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).

Solution 3

When you create private field name and a simple public property Name that actually gets and sets the name field value

public string Name
{
   get { return name; }
}

and you use this property everywhere outside your class and some day you decide that the Name property of this class will actually refer to the lastName field (or that you want to return a string "My name: "+name), you simply change the code inside the property:

public string Name
{
   get { return lastName; //return "My name: "+name; }
}

If you were using public field name everywhere in the outside code then you would have to change name to lastName everywhere you used it.

Solution 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.

Solution 5

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.

View more solutions

Comments

[John Saunders]

=1: where do you get that fields cannot be serialized?

[Russell Steen]

"You may eventually need a more complex getter or setter, but if it's a field, changing it would break the API." Not really. You can safely go from: public int Joe; to private int _joe; public int Joe { get { //do something } set { //do something } } You may have to change a lot of internal references, but that doesn't break your API.

[agnieszka]

Ok but he doesn't need to do anything else than just returning the _email. And then what, what is the reason of usng property? And the reason is in m yanswer - for the future use.

[Max Schmeling]

@John Saunders that's what I've read... is it not true? was it ever true?

[Max Schmeling]

@Russel Steen okay, maybe not break the API, but you'll have to recompile

[Max Schmeling]

@John Saunders: i guess it's a little true msdn.microsoft.com/en-us/library/ms950721.aspx

[Callum Rogers]

Reread the question - I need these private fields to be accessible from outside the class in this case. Of course you would not make every field public or give every field a property!

[Callum Rogers]

Thanks for the "public int Age { get; set; }" tip

[John Saunders]

Actually, the question says nothing about what you need, only about what you've seen public properties being created for every private field. If you have fields that require public access, then they are not private fields, and do not match what you were asking the question about. Please edit the question to make it clear what your code has in it, as opposed to the examples you've seen "on SO, thecodeproject.com"

[John Saunders]

Why do you think that fields cannot be serialized?

[John Saunders]

@Max: First of all, what year is this? That article is six years old! Please be careful with old articles. MSDN retains all sorts of worthless information. The issue with fields is that private fields cannot be serialized by XML Serialization. But XML serialization is pretty much "legacy" technology today in any case. The Data Contract Serializer has no problem with private fields.

[supercat]

For some types, such scenarios are realistic. For others, they are not. Can you think of anything at all that a future version of Point might usefully do in a property getter or setter? If Point were a class with virtual properties, future derived classes might be able to add useful behaviors, but since particular Point instances have no clue about what they're being used for, and are expected to accept any Int32 values for X and Y, I can't think of anything a future implementation could possibly add.

[user2211290]

Using properties is preferable to using fields because you can change the statements in the get and set blocks without needing to change the classes that depend on the property.