When should you use a field rather than a property?

Question

Can anyone clearly articulate when you use a field and when to use a property in class design?

Consider:

public string Name;

Or:

private string _Name;
public string Name
{
   get { return _Name; }
   set { _Name = value; }
}

I realize that the second method is more proper and flexible, so that's what I try to use, generally.

But then why do I see people use the first method? Are they just lazy, or is there some specific situation where it's the correct choice? Is it just a matter of preference?

Answer 1

Well in C# 3.0 you can actually write:

public string Name {get; set;}

Which allows you to be proper and lazy.

Generally speaking, with properties, you get proper encapsulation. You have the choice to allow setting a value, or getting it, or both. Using a public member, you don't have that option.

It's probably one-part preference, and one-part how your team decides to handle quick and dirty class definitions, but I would say, use properties for get/sets.

To answer

Can anyone clearly articulate when you use an attribute and when to use a property in class design?

You shouldn't ever use a public attribute. You should always use a property instead. It's safer and more flexible. That said, people will be lazy, and just use a public member. However, with C# 3.0 you can use a more terse syntax to define properties, which should satisfy your inner laziness.

Answer 2

Properties are more maintainable than fields, you can encapsulate logic in your setters/getters, allowing you to hide the implementation.

They also make refactoring easier.

More information:

• Property Usage Guidelines
• Field Usage Guidelines

Answer 3

Just some additional information to Alan's reply:

public string Name {get; set;}

is the same as

private string _Name;

public string Name{   
get { return _Name; }   
set { _Name = value; }
}

If you want to disallow the set function of Name, you can have

public string Name {get; private set;}

Answer 4

Using properties you can control it's security:

public string Foo { protected get; private set; }

Properties gives easy way to raise events:

public string Foo
{
  get { return _foo; }
}
set
{
  bool cancel = false;
  if(BeforeEvent != null) // EventHandler<CancelEventArgs> BeforeEvent
  {
    CancelEventArgs e = new CancelEventArgs();
    BeforeEvent(this, e);
    cancel = e.Cancel;
  }
  if(!cancel)
  {
    _foo = value;
    if(AfterEvent != null) // EventHandler<EventArgs> AfterEvent
    {
      AfterEvent(this, new EventArgs());
    }
  }
}

Also I often use code like this:

string Foo
{
  set
  {
    IsFooSet = value != null;
  }
}

bool IsFooSet
{
  get { return _isFoo; }
  set
  { 
   _isFoo = value;
   if(value) // some event raise or controls on form change
  }
}

Answer 5

When you make the field public, you allow the user to do whatever they want to do to the field. They can assign unexpected values, invalid values, values that can cause overflow, etc.

With the property, you have control over whether to allow the setting of new values to the field, massaging the value before storing it, notifying interested parties about the change of the field's value, etc. And the same idea for returning value through the getter. For .NET framework from 2.0 up, you can set the accessor for the getter, setter. Say, you only want the user to only have read access to the field, then you make the getter public, but the setter private or protected.

Answer 6

In addition to the already-given reasons for preferring properties, there's also lots of cool stuff in System.ComponentModel to do with data binding and change notification that only works with properties, rather than fields. For example, look at the documentation around PropertyChangedHandler.