C# Syntax Question

Question

public int Age {  get;  set; }

OR

public int Age;

Inside of Main, if I create this new Person. The two above lines are exactly the same Correct?

Answer 1

Not correct. The first line is an auto-implemented property while the second is a public field. They are neither binary compatible nor even semantically quite the same. Generally properties are preferred for their flexibility and the fact that they can be used to encapsulate data (though they are often abused).

But just in terms of what the compiler generates, the property creates an auto-backing field and, essentially, two methods (a "getter" and a "setter") to access it. The field is just that: a field.

Due to these differences there are in fact a number of ways your two examples will behave differently:

1. The property will support data binding in UI applications.
2. The field will be accessible as a ref or out parameter, such as to one of the Interlocked methods.
3. If rather than int you had a mutable value type (such as Point ), the property would not permit you to modify the value directly as it would return a copy of the field. (To modify the field, you would need to assign the value returned by the property to a local variable, modify the local, and then assign it back to the property.) The field would in fact allow you to modify the value correctly.

As a side note, point 3 above is an example of the type of behavior many developers use to argue against ever designing mutable value types.

Answer 2

No - the first is a field, the second is a Property. Use properties whenever possible so you can extend them later, ie add some data validation in the setter. Properties use a backing field, automatic properties just hide this for you.

Here an example of data validation within a property setter:

private int _age;
public int Age 
{  get { return _age; }
   set { if(value < 200) _age = value;}
}

One of the main reasons to use a property instead of a field is versioning of your application or library - If you use a property, you can change the property implementation without requiring users of your class or library to recompile their code, the public interface of your class remains the same. On the other hand going from a field to a property later on can at worst be a breaking change (see Dao's list, using a field as ref) and at best at least requires recompilation.

Answer 3

No, they are not the same.

The first is a property, which means that another backing variable will be created for you, along with a getter and setter method. These will be invisible. You should use this method because then you can easily change the functionality of the getter and setter classes (although in Visual Studio, converting a field into a property is pretty trivial.)

The second is just a member variable that's public to everybody, which is a bad idea because it breaks encapsulation.

Answer 4

And just to give a practical example of where they're different, the second version won't be serialized or databound to controls, whereas the first one can be. This bit me on the ass before.

Answer 5

The first is a automatic property and the second is a "capitalized" member variable. Encapsulation favors the first. In the first case, there is code point on setting and getting, albeit empty.