Fields vs Properties

After this lesson you can

• Expose a private field through a property with get and set

Key takeaways

• A property is read and assigned like a field, but its get runs when it's read and its set when it's assigned.
• In a set, value is whatever was assigned: in fridge.Temperature = 34;, value is 34.
• A set can check the value first, so the object never holds one that makes no sense, such as a refrigerator at 95 degrees.
• The usual C# style is private camelCase fields, such as temperature, and public PascalCase properties, such as Temperature.

Private fields keep an object's data safe, but other code often needs to read it, and sometimes to change it. In the last lessons, GetTemperature() did the reading. Many languages write a pair of methods for each value: GetTemperature() and SetTemperature(...). C# has a better tool: the property.

A property is a field with gatekeepers

From outside, a property looks just like a public field: you read it and assign to it with no parentheses. Inside, it runs code: a get when it's read, and a set when it's assigned.

Refrigerator fridge = new Refrigerator();
fridge.Temperature = 34;
Console.WriteLine(quot;Set to {fridge.Temperature} degrees");

public class Refrigerator
{
    private int temperature = 37;

    public int Temperature
    {
        get { return temperature; }
        set { temperature = value; }
    }
}

Set to 34 degrees

• The field temperature (camelCase, private) holds the value. It's called the property's backing field.
• The property Temperature (PascalCase, public) is the way in.
• In set, the word value is whatever was assigned: in fridge.Temperature = 34;, value is 34.

Why not a public field?

A public field lets anyone put anything in it. A property's set can check the value first, so the object can never be put into a state that makes no sense:

Refrigerator fridge = new Refrigerator();
fridge.Temperature = 34;
fridge.Temperature = 95;
fridge.Temperature = -10;
Console.WriteLine(quot;Temperature: {fridge.Temperature}");

public class Refrigerator
{
    private int temperature = 37;

    public int Temperature
    {
        get { return temperature; }
        set
        {
            if (value >= 32 && value <= 45)
            {
                temperature = value;
            }
        }
    }
}

Temperature: 34

95 and -10 aren't safe refrigerator temperatures, so the set ignores them, and the temperature stays at 34. Code that uses the class doesn't have to remember the rule; the class enforces it.

That's encapsulation at work: the data is private, and every change passes through code the class controls. If the rule changes later, it changes in one place, and every caller stays the same.

Fields and properties, side by side

The usual C# style: fields are private, and anything others need is a property.

Check yourself

2 questions to try on the lesson page.

So what

Properties let a class share its data the easy way, with plain reads and assignments, while keeping the final say over every change.

Key terms

• Property
• Getter
• Setter
• Backing Field

Cheat sheets

• Fields vs Properties