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

Question

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.

Solution 1

You should not worry about the extra code needed for accessing fields via properties, it will be "optimized" away by the JIT compiler (by inlining the code). Except when it is too large to be inlined, but then you needed the extra code anyway.

And the extra code for defining simple properties is also minimal:

public int MyProp { get; set; } // use auto generated field.

When you need to customize you can alway define your own field later.

So you are left with the extra layer of encapsulation / data protection, and that is a good thing.

My rule: expose fields always through properties

Solution 2

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.

Solution 3

One of the nice things about Properties is that the getter and the setter can have different levels of access. Consider this:

public class MyClass {

  public string MyString { get; private set; }

  //...other code
}

This property can only be changed from within, say in a constructor. Have a read up on Dependency Injection. Constructor injection and Property injection both deal with setting properties from some form of external configuration. There are many frameworks out there. If you delve into some of these you will get a good feel for properties and their use. Dependency injection will also help you with your 3rd question about good practice.

When looking at other people's code, you can tell whether something is a method or a property because their icons are different. Also, in Intellisence, the first part of a property's summary is the word Property.

Solution 4

While I absolutely dislike directly exposing fields to the public, there's another thing: Fields can't be exposed through Interfaces; Properties can.

Solution 5

1. There are several reasons why you might want to use Properties over Fields, here are just a couple:

   a. By having the following

   public string MyProperty { get; private set; }
   

   you are making the property "read only". No one using your code can modify it's value. There are cases where this isn't strictly true (if your property is a list), but these are known and have solutions.

   b. If you decide you need to increase the safety of your code use properties:

   public string MyProperty
   {
       get { return _myField; }
       set
       {
           if (!string.IsNullOrEmpty(value))
           {
               _myField = value;
           }
       }
   }
   

2. You can tell they're properties because they don't have (). The compiler will tell you if you try to add brackets.

3. It's considered good practise to always use properties.

View more solutions

Comments

[Fredrik Mörk]

Duplicate? stackoverflow.com/questions/2911945/…

[Roman]

Seems like no one linked to Why Properties Matter yet. In the past I've found that overview quite helpful.

[ChrisF]

@Josh - readonly means that the value can't be changed anywhere - not even in the same class. Using a property with a private setter means you can modify the value inside the class, but the users of your class can't.

[Jo So]

2) is exactly the reason why I don't agree with 1). Properties make code reading difficult at the call site.

[user3431501]

Asking this additional question here because it has the most upvotes. What about private members? Do you prefer properties over fields still?

[kemiller2002]

After thinking about it, in truth I don't normally use properties for private members. This is probably because of my style of programming. The internal variables I create are often readonly.