Private variable vs property?

Question

When setting a value to a variable inside of a class most of the time we are presented with two options:

private string myValue;
public string MyValue
{
   get { return myValue; }
   set { myValue = value; }
}

Is there a convention that determines how we should assign values to variables inside of our classes? For example if I have a method inside the same class should I assign it using the property or using the private variable. I've seen it done both ways, so I was wondering if this is a choice or performance is a factor (minor, probably).

Answer 1

I would take it a step further, and bring it to 3 cases. Although there are variations on each, this is the rules I use the majority of the time when C# programming.

In case 2&3, always go to the Property Accessor (not the field variable). And in case 1, you are saved from even having to make this choice.

1.) Immutable property (passed in to constructor, or created at construction time). In this case, I use a field variable, with a read-only property. I choose this over a private setter, since a private setter does not guarantee immutability.

public class Abc
{ 
  private readonly int foo;

  public Abc(int fooToUse){
    foo = fooToUse;
  }

  public int Foo { get{ return foo; } }
}

2.) POCO variable. A simple variable that can get/set at any public/private scope. In this case I would just use an automatic property.

public class Abc
{ 
  public int Foo {get; set;}
}

3.) ViewModel binding properties. For classes that support INotifyPropertyChanged, I think you need a private, backing field variable.

public class Abc : INotifyPropertyChanged
{
  private int foo;

  public int Foo
  {
    get { return foo; }
    set { foo = value;  OnPropertyChanged("foo"); }
  }
}

Answer 2

Generally, I would say assign to the field in the constructor and use the property everywhere else. This way, if someone adds functionality to the property, you won't miss it anywhere.

It certainly isn't a performance factor. The optimiser will inline a simple get or set for you and the final MSIL code will probably be identical.

Answer 3

Depends.

First you should prefer automatic properties when possible:

public string MyValue {get;set;}

Second the better approach would probably be to use the properties, if you have any logic there you should probably be passing through it yourself, especially if that logic is thread synchronization.

But you should also take into account that it might hamper your performance (a little bit), if you are synchronizing incorrectly you can deadlock yourself, and sometime the correct path is to go around the logic in the property.

Answer 4

Well, the straight-to-the-point approach would be to just assign it to the variable itself, since you're inside a class' method and you control the class' behaviour, anyway.

But the whole point about properties is that they abstract the variable away. Whereas such a simple property as in your example has completely no use over just a simple public member variable, properties usually do (or should do) additional things inside their getters and setters. And if you want these things done automatically when changing the property inside the class, then it is of course cleaner to work on the property instead of the variable to not have to change each variable assignment when the property setting behaviour changes.

You just have to reason about it conceptually. The property is actually a handle to access some internal state of the object, which may be comprised of more than one member variable. So you have to ask yourself if you want to change the underlying internal state only (or only part of it) or the abstract property representing this state at a whole, and most times it's indeed the latter since you usually want your object to always have a consistent state.

Answer 5

If there is any chance that those property get/set implementation will change sometimes later (for example, you want to rise an event when calling set, or you will add some lazy evaluation mechanism later to your get function), then it may be a good idea that your code inside the class will use the property in almost all cases except for the - most probably rare - cases where you explicitly don't want those event or lazy evaluation mechanisms to be used.

Anyhow, whatever you will do, there is a good chance that when you change the property implementation later in such a way, you will have to look at all places inside your class accessing those property to check if really the property shall be accessed or the private variable shall be used.

Answer 6

I always use the public property.

Often some logic which should always run when the property is set is added to the set method of a property, and setting the private field instead the public setter will bypasses any logic there.

You have a comment about MVVM leading to this question, and I feel this is even more important when working with MVVM. Many objects raise a PropertyChange notification the setter, and other objects can subscribe to this event to execute some action when specific properties change. If you set the private variable, these actions will never execute unless you also manually raise the PropertyChanged event.

Answer 7

Generally, it's up to you what you should do with a property and its backing field when getting/setting.

Most often, just to be consistent across code, you should use public accessors wherever they are available and appropriate. That allows you to refactor with minimal code change; if the method doing this setting needs to be stripped out of the class and put somewhere else where the backing field is no longer available (like a base class), who cares? You're using something that's available wherever the class itself is to do the job. The backing field, in most cases, is an implementation detail; nobody outside your class should know it exists.

The main situation I can think of when you should use the backing field and NOT the property accessor is when the accessor has additional logic (validation, or updating other state information in the class) which you don't want to run. Initial population of an object is an example; you may have a class that uses two property values to calculate a third, which is also stored in a backing field (for persistence reasons). When initializing a new copy of that object given data from the DB, the property accessors which each recalculate the third value may complain if the other needed value is not set. By using the backing fields to set the initial values of these two (or three) properties, you bypass the validation/calculation logic until the instance is in a consistent enough state for the logic to work normally.

Answer 8

Always use the one that makes sense. Yes, I know that sounds pretty bogus to the point of being a non-answer.

The point of properties is to provide an interface through which you can safely access a data model. For most situations you always want to safely access the data model through that interface, such as:

public Foo Bar
{
  get { return _bar; }
  set { _bar = doSomethingTo(value); }
}

But in other situations, you may simply be using a property as a view of a data model:

public Double SomeAngleDegrees
{
  get { return SomeAngleRadians * 180 / PI; }
  set { SomeAngleRadians = value * PI / 180; }
}

If it makes sense to use the radians form of SomeAngle, then by all means use it.

In the end, be sure to drink your own kool-aid. Your public-facing api should be resilient enough to work internally.