Properties VS. Fields: Need Help Grasping the Uses of Properties Over Fields

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

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

What's the reason for peoples to use properties with get; set; instead of fields?

The main reason is encapsulation - the value can only be changed trough the corresponding properties, and this continues to be the case even if you later decide that the property shouldn't just return a value. Maybe you find that you'll want to fire an event when a value changes? If you've got a property, that's very easy. If you've got a public field, you need to make a breaking change.

In addition, properties can be virtual or declared in interfaces. And they can be declared read-only.

Oh, and it helps in debugging: You can set a breakpoint on the "set", if you want to know who is changing your value (unexpectedly).

What is the difference between a field and a property?

Properties expose fields. Fields should (almost always) be kept private to a class and accessed via get and set properties. Properties provide a level of abstraction allowing you to change the fields while not affecting the external way they are accessed by the things that use your class.

public class MyClass
{
    // this is a field.  It is private to your class and stores the actual data.
    private string _myField;

    // this is a property. When accessed it uses the underlying field,
    // but only exposes the contract, which will not be affected by the underlying field
    public string MyProperty
    {
        get
        {
            return _myField;
        }
        set
        {
            _myField = value;
        }
    }

    // This is an AutoProperty (C# 3.0 and higher) - which is a shorthand syntax
    // used to generate a private field for you
    public int AnotherProperty { get; set; } 
}

@Kent points out that Properties are not required to encapsulate fields, they could do a calculation on other fields, or serve other purposes.

@GSS points out that you can also do other logic, such as validation, when a property is accessed, another useful feature.

Properties in C# advantage

From personal experience:

You would generally have Private data member when you do not want it to be accessed externally through another class that calls the class containing the Private data member.

Public data members are those that you can access by other classes to obtain its contents.

My opinion is that it is simply proper programming syntax. Private data members are typically those of constants that you do not wish to override once it had been set, while Public are algebraic-like variables, subject to be overridden if necessary.

A similar question has been asked at:
What is the difference between Public, Private, Protected, and Nothing?.

Cheers,

iato

Why do we need the backing fields in EF Core?

Properties do not store anything. They are a pair of set and get methods. You must have a backing field to have them store something.

public class Data
{
    private int _id; // Backing field used by property to store the value.

    // Property whose name is used by EF Core to map to a column name.
    public int Id
    {
        get { return _id; }
        set { _id = value; }
    }

    ... more properties
}

But you can simplify this code by using automatic properties

public class Data
{
    // Auto-implemented property. Backing field and implementation are hidden.
    public int Id { get; set; }

    ... more properties
}

This 2nd code snippet does exactly the same as the first one.

---

EF Core prefers backing fields over properties if their name can be inferred from the property name. The Conventions say:

By convention, the following fields will be discovered as backing fields for a given property (listed in precedence order). Fields are only discovered for properties that are included in the model. For more information on which properties are included in the model, see Including & Excluding Properties.

• _<camel-cased property name>
• _<property name>
• m_<camel-cased property name>
• m_<property name>

---

Related Topics