Why do I need a private field that is exposed via public property?

Question

I\'m comming from Java world mainly. So, C# properties do look nice.

I know that with C# 3.0 or above I can use Automatic Properties. I like it even more :).

Answer 1

With the automatic properties, you don't need to do this. There's nothing wrong with it, but with automatic properties you'll still have your property signature, which is the important thing. Before automatic properties, you had to have a backing field for your property. As long as you have an automatic property, you can later change it to the format with an explicit backing field, and the signature stays the same.

But, there's nothing wrong with it. Except that the convention is becoming more to call the private backing field "_age".

(I assume you know why you want to have a property, whether automatic or not, instead of a public field. The reason is that the object has a different signature if you change form public field to public property, so it's safest to just start off with a property, even if there is no extra logic.)

Answer 2

Older versions of C# didn't have automatic properties, so you had to declare your variables that the properties acted upon like in your example. These days, the same code could be expressed as:

public int Age { get; set; }

I think that answers your question. However, if you are asking "why not just have public int Age; and let programmers set the value on the field directly?", then:

First thing to keep in mind is that property accessors are compiled into methods. This means that it has a different ABI from just reading/writing to a class member variable, even though it may syntactically look the same as if you had:

class Fu {
  public int Age;
}

So, what this means is that if, at some point down the road, you need to add some notification that the Age field has changed - if you are using properties, you can easily add this notification logic to the property setter without breaking ABI.

public int Age {
  get { return age; }
  set { age = value; NotifySomeOtherCode (); }
}

If you start off with a public field, then later changing it to a property will change the ABI which is bad for any program(s) that may depend on your assembly. So it's better to start off with properties.

Hopefully I'm making sense...

Answer 3

The bog-standard answer would be "encapsulating the implementation detail of how and where the age is stored".

For retrieval purposes, a more realistic example might be that one day, you could potentially want to access the value in a way that means direct access isn't so good. For example, if it's a value that you might be caching elsewhere, or if it's a calculated value.

In terms of encapsulating the setting process, it means you can embed some model-level validation into the setter; if someone tries to set a conceptually invalid value, you can throw an IllegalArgumentException and reject it.

In these cases, the encapsulation means that all your existing code doesn't have to change because you had to wrap up the value in something.

Answer 4

The automatic properties were not supported in older versions of the C# compiler.

The above code is more or less equivalent to this (assuming that the field is never actually used directly):

public int Age {
  get;
  set;
}

Answer 5

In the simple case nothing. However you are making it easier to maintain the interface to the class should the implementation of either of those two methods require additional code.

Take for instance if you need to add a changing event to the setter.

   public int Age {

     get { return age; }
     set { 
          if ( age != value) {
              age = value; 
              OnAgeChanged();
          }
      }     
   }

You can do this with a property and not break client code. A field does not have this advantage.

Answer 6

In this case you aren't hiding anything but it will give you the freedom to add get/set logic to your private field later. So anyone who uses the property wont notice the difference in the future.