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

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 4

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 5

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.