6

Possible Duplicates:
c#: why have empty get set properties instead of using a public member variable?
C#: Public Fields versus Automatic Properties

I am using "automatic" properties in my code, and I wonder what is the actual difference between this code:

public class foo{
    public int i;
}

and 

public class foo{
    public int i {get; set;}
}

I know there is a difference, as sine 3rd parties that I've used missed the public members but found them once adding the {get; set;}.

AS there is no private field behind that, what is going behind the scene ?

Community
  • 1
  • 1
Dani
  • 14,639
  • 11
  • 62
  • 110
  • I found some answers in the questions at the comment, but still, I don't understand what happens under the cover between a property and a field. is a property is a function ? not a function ? – Dani Jan 20 '11 at 20:13

3 Answers3

5

A private field gets generated by the compiler when using automatic properties.

When you declare a property as shown in the following example, the compiler creates a private, anonymous backing field that can only be accessed through the property's get and set accessors.

In regards to the difference between the two examples - the first one exposes the field directly for manipulation. This is considered bad practice (think information hiding, loss of encapsulation).

With the second example, you must use the getter and setter and you can add any kind of validation and other logic around these actions.

See this blog post:

If I have a field with no special behavior, should I write a "just in case" property (with trivial get/set), or should I expose a public field?

The reason that the library design guidelines suggest you write a property here is that it is important that libraries be easily versioned. If you put a property in there ahead of time, you can change the property implementation without requiring users to recompile their code.

Community
  • 1
  • 1
Oded
  • 489,969
  • 99
  • 883
  • 1,009
  • I know that. but what makes the difference between property to a public field ? why some code can reach a property but not a public field by the same name ? – Dani Jan 20 '11 at 19:55
  • @Dani - was answering as you were commenting :) – Oded Jan 20 '11 at 19:56
  • @Downvoter - care to comment? – Oded Jan 20 '11 at 20:02
  • @Oded - can I consider the property as a function - in regards to what happens under the hood? – Dani Jan 20 '11 at 20:17
  • @Dani - You could treat them as such, though they do not have parameters. – Oded Jan 20 '11 at 20:18
  • @Oded - thanks, I'm trying to understand what the compiler does under the hood- if a property is a parameter-less function, than I "understand" it. if it's something else, I would like to know what.... – Dani Jan 20 '11 at 20:20
  • @Dani - I suggest you get a copy of the free and wonderful [Reflector](http://www.red-gate.com/products/dotnet-development/reflector/). You will see quite a lot of under the hood stuff with it. – Oded Jan 20 '11 at 20:22
1

That's an auto property, not an anonymous property. There is, in fact, a private backing field for it, it's just generated automatically by the compiler and isn't available to you at compile time. If you run your class through something like Reflector (or examine it at runtime with reflection), you'll see the backing field.

To answer your question of "What's the difference?", the obvious answer is that one is a field, whereas one is a property. The advantage to using auto properties is that it gives you the flexibility to move to traditional properties later, should the need arise, without changing your API. As far as third party code being able to "reach" one but not the other, that would be a question best answered by the other developer. That being said, most API's are designed to work on properties, not fields (since conventional wisdom is that you do not expose fields outside of the declaring class). If the third-party library is reflectively scanning your class, then it's likely only looking for properties.

The important thing to remember is that:

private string backingField;

public string Data
{
    get { return backingField; }
    set { backingField = value; }
}

and

public string Data { get; set; }

Are compiled to essentially the same code. The only substantive difference is the name of the backing field.

Adam Robinson
  • 182,639
  • 35
  • 285
  • 343
1

The first is a field and could be described as POD. The second is a property and allow for derived classes to overload and Shadow while the first does not. Also the second is a nicety since the complier silently creates a backing store.

rerun
  • 25,014
  • 6
  • 48
  • 78