What is the difference between public int i and public int i {get; set;} (what is the difference between automatic property and a public member?) [duplicate]

This question already has answers here: Closed 12 years ago.

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 go开发者_开发百科ing behind the scene ?

---

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.

---

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.

---

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.