Please explain how C# properties work?

Question

I\'ve been learning C# for a while now, and I\'ve come across properties in my C# book (Head First C#). I honestly do not understand what they\'re used for, and why I should

Answer 1

Are you familiar with fields, then? If so, from the point of view of code that consumes your class, properties are exactly like fields. Inside your class though, a property is like a pair of methods, one that deals with returning the value to the consumer, and one method that deals with updating the value. These methods are generally called getters and setters.

A good reason for wanting to use a property instead of a field is that it gives you better control of the values passing in and out of the property.

Answer 2

Properties provide controlled access to data; at the most basic, it can just mean encapsulating a field (public fields are not recommended), which the compiler can make easy for you:

public int Foo {get;set;} // the compiler handles the field for you

You could, however, use the property to enforce logic or handle side effects:

private int foo;
public int Foo {
    get { return foo; }
    set {
        if(value < 0) throw new ArgumentOutOfRangeException();
        if(value != foo) {
            foo = value;
            OnFooChanged(); // fire event notification for UI bindings
        }
    }
}

Other common options are lazy-loading, calculated members, proxied members, etc.

You can also change the accessibility, for example:

public int Foo { get; protected set; }

which can only be assigned by the type and subclasses, not by unrelated code. It could also only have a get or set.

Basically, properties act as a more formal version of a get/set pair of methods, making it much easier to talk about "Foo", rather than "get_Foo"/"set_Foo" etc (for two-way binding).

Unlike fields, properties can also be advertised on interfaces, which is essential for interface-based code

Answer 3

Properties are used to enrich the Encapsulation concept of Object-Oriented Programming.

i.e. They encapsulate a field-member and let you (the developer) control how setting/getting this variable is done. Example?

public class Person
{
    private int m_age;

    public int Age
    {
        set
        {
            if(value < 18)
                m_age = 18;
            else
                m_age = value;
        }
        get
        {
            return m_age;
        }
    }
}

See? using property Age, we guaranteed that the minimum set value of age is 18.

Answer 4

Though the other answers are pretty good, they are all very much about the mechanism of properties. It is also helpful to understand the philosophy of properties.

In OO programming we spend a lot of time building models of semantic domains. When you say that you have a class "Animal" and a derived class "Tiger", you're modeling in the computer realm a fact about the real world: that of all things in the world, some of them are animals, and of those animals, some of them are tigers.

But you have to understand that the mechanism and the semantics are different. No one says "hey, let's go to the zoo and watch the instances of zookeeper invoke methods on IFeedable on the instances of the tigers".

A field is a mechanism and therefore should be a private implementation detail of a class; it does not describe part of the model. A property is a part of the semantic model. Every tiger has a birthday, so "Birthday" should be a property of the Tiger class. That's part of the "semantic model" of tigers, so expose it as a property. As an implementation detail, the birthday might be stored in a private field accessed by the property.

Does that make sense? In short: use public properties to describe the semantic properties of the things you are modeling; use private fields as implementation mechanisms.