Class definition, using { get; set;}

Question

In the past we declared classses like:

public class MyClass
{
    private int _age;

    public int Age
    {
          get{ return _age;  }
          set{ _age = value; }
    }
}

Now we can do:

public class MyClass
{
    public int Age {get; set;} 
}

My question is, how can I access the private variable that is created automatically using this notation?

I would rather access the private variable and not the public accessor 'Age' ? Is there a default notation to access the private variable, or it is just not possible?

Answer 1

You can't, it's a language feature as opposed to a IDE feature. To be honest i'd prefer then IDE to add the private variable in for you. I agree that it is slightly weird for the class to internally have to use the public entry point to access its own variables. Hence I don't use this new feature that much myself.

Answer 2

Behind the scenes what happens is the injection of a private member variable, prefixed with <>k__AutomaticallyGeneratedPropertyField#

From C# 3.0 Automatic Properties explained

Although it may be possible to use that private member directly, it's very hacky and unnecessary.

Answer 3

This syntax is commonly called "syntax sugar", which means that the compiler takes that syntax and translates it into something else. In your example, the compiler would generate code that looks something like this:

[CompilerGenerated]
private int <Age>k_BackingField;

public int Age
{
   [CompilerGenerated]
   get
   {
      return this.<Age>k_BackingField;
   }
   [CompilerGenerated]
   set
   {
      this.<Age>k_BackingField = value;
   }

Even knowing all of that, you could probably access the backing field directly but that sort of defeats the purpose of using automatic properties. I say probably here because you then depend on an implementation detail that could change at any point in a future release of the C# compiler.

Answer 4

Your usage of automatic properties implies that you do not need any getting/setting logic for the property thus a private backing variable is unneccessary.

Don't use automatic properties if you have any complex logic in your class. Just go private int _age and normal getters/setters as you normally would.

IMO, automatic properties are more suited for quickly implementing throwaway objects or temporary data capsules like:

public class TempMessage {
    public int FromID { get; set; }
    public int ToID { get; set; }
    public string Message { get; set; }
}

Where you don't need much logic.

Answer 5

The aim of the new automatic properties is to reduce the ammount of boiler plate code you need to write when you just have a simple propertly that doesn't need any special logic in the get or the set.

If you want to access the private member that these properties use, that's usually for a few reasons:

• You need to more than just a simple get/set - in this case, you should just avoid using automatic properties for this member.
• You want to avoid the performace hit of going through the get or set and just use the member directly - in this case, I'd be suprised if there really was a performace hit. The simple get/set members are very very easy to inline, and in my (admitly limited) testing I haven't found a difference to using the automatic properties vs accessing the member directly.

• You only want to have public read access (i.e. just a 'get') and the class write to the member diectly - in this case, you can use a private set in your automatic property. i.e.

  public class MyClass
  {
      public int Age {get; private set;} 
  }

This usually covers most the reasons for wanting to directly get to the backing field used by the automatic properties.

Answer 6

You shouldn't, and it's very unlikely you need to. If you need to access the property, just use the public property (e.g. this.Age). There's nothing special about the private field backing the public property, using it in preference to the property is just superstition.