Properties vs. Fields: Need help grasping the uses of Properties over Fields

pghtech picture pghtech · Jun 18, 2010 · Viewed 11.5k times · Source

First off, I have read through a list of postings on this topic and I don't feel I have grasped properties because of what I had come to understand about encapsulation and field modifiers (private, public..ect).

One of the main aspects of C# that I have come to learn is the importance of data protection within your code by the use of encapsulation. I 'thought' I understood that to be because of the ability of the use of the modifiers (private, public, internal, protected). However, after learning about properties I am sort of torn in understanding not only properties uses, but the overall importance/ability of data protection (what I understood as encapsulation) within C#.

To be more specific, everything I have read when I got to properties in C# is that you should try to use them in place of fields when you can because of:

1) they allow you to change the data type when you can't when directly accessing the field directly.

2) they add a level of protection to data access

However, from what I 'thought' I had come to know about the use of field modifiers did #2, it seemed to me that properties just generated additional code unless you had some reason to change the type (#1) - because you are (more or less) creating hidden methods to access fields as opposed to directly.

Then there is the whole modifiers being able to be added to Properties which further complicates my understanding for the need of properties to access data.

I have read a number of chapters from different writers on "properties" and none have really explained a good understanding of properties vs. fields vs. encapsulation (and good programming methods).

Can someone explain:

1) why I would want to use properties instead of fields (especially when it appears I am just adding additional code

2) any tips on recognizing the use of properties and not seeing them as simply methods (with the exception of the get;set being apparent) when tracing other peoples code?

3) Any general rules of thumb when it comes to good programming methods in relation to when to use what?

Thanks and sorry for the long post - I didn't want to just ask a question that has been asked 100x without explaining why I am asking it again.

Answer

kemiller2002 picture kemiller2002 · Jun 18, 2010

1) why I would want to use properties instead of fields (especially when it appears I am just adding additional code

You should always use properties where possible. They abstract direct access to the field (which is created for you if you don't create one). Even if the property does nothing other than setting a value, it can protect you later on. Changing a field to a property later is a breaking change, so if you have a public field and want to change it to a public property, you have to recompile all code which originally accessed that field.

2) any tips on recognizing the use of properties and not seeing them as simply methods (with the exception of the get;set being apparent) when tracing other peoples code?

I'm not totally certain what you are asking, but when tracing over someone else's code, you should always assume that the property is doing something other than just getting and setting a value. Although it's accepted practice to not put large amounts of code in getters and setter, you can't just assume that since it's a property it will behave quickly.

3) Any general rules of thumb when it comes to good programming methods in relation to when to use what?

I always use properties to get and set methods where possible. That way I can add code later if I need to check that the value is within certain bounds, not null etc. Without using properties, I have to go back and put those checks in every place I directly accessed the field.