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.

Answer 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

Answer 2

Properties are the preferred way to cover fields to enforce encapsulation. However, they are functional in that you can expose a property that is of a different type and marshal the casting; you can change access modifiers; they are used in WinForms data binding; they allow you to embed lightweight per-property logic such as change notifications; etc.

When looking at other peoples code, properties have different intellisense icons to methods.

If you think properties are just extra code, I would argue sticking with them anyway but make your life easier by auto-generating the property from the field (right-click -> Refactor -> Encapsulate Field...)

Answer 3

There are many scenarios where using a simple field would not cause damage, but
a Property can be changed more easily later, i.e. if you want to add an event whenever the value changes or want to perform some value/range checking.

Also, If you have several projects that depend on each other you have to recompile all that depend on the one where a field was changed to a property.

Answer 4

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

You want to use properties over fields becuase, when you use properties you can use events with them, so in a case when you want to do some action when a property changes, you can bind some handlers to PropertyChanging or PropertyChanged events. In case of fields this is not possible. Fields can either be public or private or protected, in case of props you can make them read-only publicly but writable privately.

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?

A method should be used when the return value is expected to be dynamic every-time you call, a property should be used when the return value is not that greatly dynamic.

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

Yes, I strongly recommend to read Framework Design guidelines for best practices of good programming.

Answer 5

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.

Answer 6

Properties allow you to do things other than set or get a value when you use them. Most notably, they allow you to do validation logic.

A Best Practice is to make anything exposed to the public a Property. That way, if you change the set/get logic at a later time, you only have to recompile your class, not every class linked against it.

Answer 7

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.

Answer 8

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.

Answer 9

I was going to say Properties (setters) are a great place to raise events like NotifyPropertyChanged, but someone else beat me to it.

Another good reason to consider Properties: let's say you use a factory to construct some object that has a default constructor, and you prepare the object via its Properties.

new foo(){Prop1 = "bar", Prop2 = 33, ...};

But if outside users new up your object, maybe there are some properties that you want them to see as read-only and not be able to set (only the factory should be able to set them)? You can make the setters internal - this only works, of course, if the object's class is in the same assembly as the factory.

There are other ways to achieve this goal but using Properties and varying accessor visibility is a good one to consider if you're doing interface-based development, or if you expose libraries to others, etc.

Answer 10

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

Answer 11

One caveat is that things like "Threading.Interlocked.Increment" can work with fields, but cannot work with properties. If two threads simultaneously call Threading.Interlocked.Increment on SomeObject.LongIntegerField, the value will get increased by two even if there is no other locking. By contrast, if two threads simultaneously call Threading.Interlocked.Increment on SomeObject.LongIntegerProperty, the value of that property might get incremented by two, or by one, or by -4,294,967,295, or who knows what other values (the property could be written to use locking prevent values other than one or two in that scenario, but it could not be written to ensure the correct increment by two).