C# Automatic Properties

Question

I\'m a bit confused on the point of Automatic properties in C# e.g

public string Forename{ get; set; }

I get that you are saving code by no

Answer 1

It is meant that you expect to add the logic later.

If you do so and have it as property from the beginning, you will not have to rebuild the dependent code. If you change it from a variable to a property, then you will have to.

Answer 2

I'm not sure what the difference between these 2 statements is, I always thought you used properties if you wanted additional get/set logic?

In the first case, the compiler will automatically add a field for you, and wrap the property. It's basically the equivalent to doing:

private string forename;
public string Forename
{
    get
    { 
        return this.forename;
    }
    set
    {
        this.forename = value;
    }
}

There are many advantages to using properties over fields. Even if you don't need some of the specific reasons, such as databinding, this helps to future-proof your API.

The main problem is that, if you make a field, but in v2 of your application, need a property, you'll break the API. By using an automatic property up front, you have the potential to change your API at any time, with no worry about source or binary compatibility issues.

Answer 3

Properties can have code put into them without breaking contract, fields can't have code put into them without changing them to properties (and breaking the interface). Properties can be read only or write only, fields can't. Properties can be data bound, fields can't.

Answer 4

Public data members are evil (in that the object doesn't control modification of it's own state - It becomes a global variable). Breaks encapsulation - a tenet of OOP.

Automatic properties are there to provide encapsulation and avoid drudgery of writing boiler plate code for simple properties.

public string ID { get; set;}

You can change automatic properties to non-automatic properties in the future (e.g. you have some validation in a setter for example)... and not break existing clients.

string m_ID;
public string ID
{
   get { return m_ID; }
   set 
   { 
     //validate value conforms to a certain pattern via a regex match
     m_ID = value;
   }
}

You cannot do the same with public data attributes. Changing a data attribute to a property will force existing clients to recompile before they can interact again.

Answer 5

Not all properties need get/set logic. If they do, you use a private variable. For example, in a MV-something pattern, your model would not have much logic. But you can mix and match as needed.

If you were to use a field like you suggested in place of a property, you can't for example define an interface to describe your class correctly, since interfaces cannot contain data fields.

Answer 6

Consider looking at some related threads about Difference Between Automatic Properties and Public Fields, Fields vs Properties, Automatic Properties - Useful or Not?, Why Not to Use Public Fields.