Public accessor .net

I think it was in .net 2.0,开发者_如何学Python microsoft introduced an accessor that was abbreviated to something like

public string Name { get; set; }

But is there any real difference between the above code, and simply:

public string Name;

---

The main difference is that if you later need to add logic into your getter or setter, and other DLLs have already been compiled against yours, you can easily change

public string Name { get; set; }

into

public string Name { get{/*special code*/} set{/*special code*/} }

and it won't be a breaking change to publish your new DLL and have other DLLs not be recompiled.

---

Whereas if you changed

public string Name;

into

public string Name { get{/*special code*/} set{/*special code*/} } 

then you'll need to make sure any DLLs that use yours are recompiled, since they change from accessing a field into accessing a property.

This is obviously a bigger problem when you're shipping DLLs to other programmers (as an open source project or as a component vendor for example) than if you're just building an app for your own self / employer

---

The difference is between a Field and a Property. A field is just a member variable on the class instance. By contrast, a property is shorthand for two separate actions - get and set:

public string Name
{
    get
    {
        return _name;
    }
    set
    {
        _name = value;
    }
}

private string _name;

This is an over-simplified example, as the property simply "wraps" the private field by returning it in the getter and setting it in the setter. However, properties become very useful when they become "gateways" to the underlying value. If program flow requires something happen every time the value of a field is set (say, an event is fired), it can be fired from the setter of the property:

set
{
    this.InvokePropertyChangedEvent();
    _name = value;
}

The exact syntax you're asking about is called Auto-Implemented Properties, which is just shorthand for the simple example I provided above. The compiler creates a private member that is got and set by the property.

---

Automatic properties were first introduced in C# 3.0. The difference between:

public string Name { get; set; }

and

public string Name;

is that the first declares a property while the second a field. In OOP properties are used to encapsulate fields. A property can have a setter or a getter or both and you can also specify different accessibility level for each.

---

There is no functional difference as far as writing code to get the value or store it. But there are cases where a caller might expect a field or a property and would only accept one or the other by using reflection. For example WPF may only bind to a property and not to a field.

---

The difference between the shorthand property declaration is that you can define it this way.

public string Name { get; private set; }

It means that property can be read publicly but only private members can write into it. You cannot do such thing for a field.

If you look at the generated IL of short-hand property declarations, you will find that the compiler has added / autogenerated member-fields to a property will read from or write into.

---

Yes, the code in the second line you are making available directly the member in memory whereas in the first line you have one level of indirection where you can add some logic in the future to validate and lazy assign.

Also, if you use a reflection, you would have to lookup for Property Setter and Getter for the first example line and for the second you would need to directly retrieve a member variable.

Usually, using Properties is a lot better design.

---

One useful difference I found for propertygrid users was that Using public string Name { get; set; } we could set the source data in Propertygrid easily.

while declaring public string Name; will not be use full for Propertygrid.