Question

Possible Duplicate:
c#: why have empty get set properties instead of using a public member variable?

string name;

vs

string name {get; set;}

Assuming your get and set are blank as above, what’s the point in specifying them?

Answer 1

It encapsulates the compiler generated field, and provides you, the class or struct developer the ability to update it internally later without breaking your API by simply modifying the get/set part that you care about.

For instance, suddenly never want to return null? You can do that by simply changing the empty get to get { return storedName ?? ""; }. Of course, it means you suddenly need to manually control the variable, but that’s a small price to pay for the flexibility.

---

The first use is an example of a field declaration. The second use is an example of an auto-implemented property.

It is generally bad practice to provide direct access to a field. However, the .NET team noticed that a lot of getters/setters are basically just that. For example, consider the following:

// C#
public string Name
{
    get { return name; }
    set { name = value; }
}

// Without properties (or a Java implementation)
public void setName(String name)
{
    this.name = name;
}

public String getName()
{
    return name;
}

Either way, that’s a lot verbosity to really just expose a field. However, it is regularly the case that, as a developer, you need to go back and change how a field is handled internally, but you do not want to break or even affect other code if you can get away with it.

That is why using direct access to fields is bad. If you provide direct access to fields, but need to change something about using the field, then all code that uses that field must change as well. If you use a property (or even a method), then you can change the internal code and potentially not effect external code.

Consider the following example:

public string Name
{
    get;
    set;
}

Later you decide that you need to raise a changing and changed event around the setter. If you exposed a field, then it’s time for a potentially big rewrite. If you used properties (or a method), then you can just add the logic there. You suddenly lose the benefit of auto-implementing properties, but you gained the ability to refactor your class without breaking existing code.

private string name;
public event NameChangingEventHandler NameChanging;
public event NameChangedEventHandler NameChanged;

public string Name
{
    get { return name; }
    set
    {
        OnNameChanging(/*...*/);
        name = value;
        OnNameChanged(/*...*/);
    }
}

protected virtual void OnNameChanging(/*...*/) { }
protected virtual void OnNameChanged(/*...*/) { }

All of that maintains your public API and requires no work from users of the class (the rest of your code, or external developers using of your API). Breaking changes are not always avoidable, but avoiding direct access to fields is a good step to try to ensure that it won’t happen. Auto-implemented properties are a quick, and easy way to do it.

(Unrelated: lost power while typing this and I am very happy that my browser saved most of it!)