Why have empty get set properties instead of using a public member variable? [duplicate]

Answer 1

The idea is to manage the values inside of the object, state, avoiding corruption and misuse by calling code.

Answer 2

One thing you can do with properties that you can't do with fields is limit visibility for either setter or getter:

public string MyProperty { get; private set; }

Something I use quite a lot.

And something (more powerful) you can't do with fields is define them inside an interface. Suppose you want an interface that requires implementing classes to have a certain property:

public interface MyInterface
{
    string MyProperty { get; }
}

Note that you do not need to have a setter here. It is entirely up to implementing classes to determine how they should set MyProperty.

Answer 3

Tight coupling comes to mind. Using public fields removes the layer of abstraction made available by the use of properties. Using private fields and properties hides the implementation from other classes and helps to insulate them (external classes) whenever a change is necessary.

Also, keep in mind that you are referring to auto-implemented properties which causes the compiler to create the backing field for you instead of you having to manually create the backing (private) field for each property on your class.

Answer 4

You can flag properties with attributes that aren't available on members. There are attributes that only apply to fields in the DataContract namespace that affects serialization, the attribute can't be applied to fields, etc.

Admittedly, there isn't anything technically preventing these attributes from being used on members, but nonetheless they only work on properties.

Answer 5

One word: inheritance.

Properties are inheritable while fields are not. You can use fields in an inherited class, but not alter their behavior by making them virtual.

Like so:

public class Foo {
  public virtual int MyField = 1; // Nope, this can't

  public virtual int Bar {get; set; }
}

public class MyDerive : Foo {
  public override MyField; // Nope, this can't

  public override int Bar {
    get {
      //do something;
    }
    set; }
}

Edit: Besides the fact of inheritance, the points pointed out in the other answers (like visibility) are also a huge benefit of properties over fields.

Answer 6

A property gives you several advantages over a simple public field:

• you can control whether the property is read-only, write-only, or read/write
• you can hide the actual implementation (maybe in the setter you want to do more than just setting a value)
• when using databinding (e.g. in ASP.NET), you'll have to use properties (does not work with fields)