Disadvantages of using properties only with no corresponding fields in .NET?

Question

I have classes which have automatic properties only like public customerName {get; set;}. They are public because they are accessed outside the class. They can also be accessed inside the class. They offer good encapsulation and better debugging. I can put a breakpoint on one if I need to know who is accessing it and when.

My question is what are the disadvantages of using properties only with no corresponding fields? I can make the setter or getter private, internal.. etc which means I also have flexibility of scoping it when needed.

Answer 1

There are no disadvantages for simple properties. The compiler creates the backing field for you. This blog entry explains how the compiler treats automatically implemented properties.

Answer 2

The thing is, there is a corresponding field. You just don't see it because the compiler creates it for you. Automatic properties are just syntactic sugar or shorthand way to create the field.

Answer 3

You can't create truly read only property, because you have to define both setter and getter. You can only use private setter to achieve pseudo-readonly property from outside.

Otherwise, as said above there are no other disadvantages.

Answer 4

No major things. Just edge cases like where you need to pass a property to a method where the parameter is passed by reference (ref or out) which isn't possible with a property (because internally, they're just get_Property/set_Property methods implemented by the compiler, not special fields of some kind) and you would need an explicit private backing field for this.

EDIT: Oh, and seconding the 'no readonly' properties, which is actually fairly common.

Answer 5

If you don't need to perform any specific logic in the get and/or set accessors, there's no disadvantage...

Answer 6

I say that they are bad from a code readability standpoint. Syntax sugar is nice for writing code but horrible for reading code. As developers the code we leave behind will ultimately be inherited by some poor developer that will have to make sense out of what we did and what is going on in the code. I really am against changing a language to simply save keystrokes when there is an established syntax for the same constructs.

Answer 7

Not really a disadvantage, but you have to be aware of the default values of automatic properties. With "classic" properties we always used to initialize the backing fields, e.g. like this:

private bool _flag = true;
public bool Flag
{
  get { return _flag; }
  set { _flag = value; }
}

This made it obvious what the default value of the property is.

With automatic properties, you have to know what the default values are for the different types (e.g. false for bool). If you don't want the property to have the default value you have to initialize it in the constructor:

class MyClass
{
  public bool Flag { get; set; }
  public MyClass()
  {
    Flag = true;
  }
}

This means, you have to implement a constructor if you want to initialize your properties to non default values or if a property is of a reference type (class).

But as I wrote, I do not really think of this as a disadvantage, just something you have to know.

Answer 8

Serialization with BinaryFormatter - you have big problems if you need to change your property to a "regular" property later, for example to add some validation / eventing /etc - sinc BinaryFormatter uses the field names. And you can't duplicate this, since the field name the compiler generates cannot be written as legal C#.

Which is a good reason to look at a contract-based serializer instead. See this blog entry for more info.