Property(with no extra processing) vs public field

Question

Whenever there is question about credibility of Properties, I see that most of the discussion happens around functions/methods vs properties. But I would also like to know the compelling reason to use property with associated private field vs public field directly itself, incase of most common get/set behaviors with no other processing, I mean this way

public string CustomerName;

vs

private string customerName;
public string CustomerName
{
get{return customerName;}
set(string value){this.customerName=value;}
}

Answer 1

You get source/binary compatibility if you later need to add other behavior, you get to add break points, and it's just philosophically cleaner (care about the behavior, not the storage mechanism).

Note that you don't need the whole of the latter block in C# 3:

public string CustomerName { get; set; }

See my article on "Why Properties Matter" for more information.

Answer 2

1. You can override or at least create a "new" property in a derived class

2. At this point people expect properties to be exposed and fields to be hidden. If someone's going to reflect over your class (its becoming more and more common with tools like Castle Windsor, NHibernate) there is a world of difference, they will likely not be checking for exposed fields.

Answer 3

This is mostly a bug in Java. In many other languages (Python, Delphi, Groovy), the compiler will generate the getters and setters for you unless you supply the code.

This means you can use a "public" field in Groovy and the compiler will silently generate and invoke the setter/setter. If you need to do additional magic when a field is changed, you can introduce a specialized setter and everything will work.

It's one of those things where reality clashes with a design. The Java designers didn't want the compiler to do anything you can't see. What seemed like a good idea many years ago, didn't turn out too well.

Answer 4

I notice one helpful use of property. If you are going to bind the collection of your object to a DataGrid or DataGridView or other bindable control, the only recognized evaluatable names are Property and not public fields.

Answer 5

You can also provide some basic validation with properties. For example to prevent setting a property to an invalid state like a negative value for a height:

private int height;
public int Height
{
  get{ return height; }
  set 
  { 
     if (value > 0)
     {
         height = value;
     }
  }
}

Answer 6

Even without any extra processing, there are still a few benefits:

1. Good coding practice. In general it is good to not expose your fields to outside classes directly and instead only allow them to access through this extra layer of abstraction. Even without extra processing, it is still good to be consistent as you might need it somewhere else in the code.
2. You might need to change a field to a property later on when you have multiple other projects depend on yours. That would require re-compiling everything.
3. You can use events with them, such as binding handlers to PropertyChanging or PropertyChanged events. In the case of fields this is not possible.