1

I have looked on stack overflow but all of the answers seem to branch off slightly different.

I want to know, plain and simple. Why is this standard practice?

Why do you create a private local variable for properties?

Why is this standard practice in ever bit of professional code I have seen written?

private int _widget;

public int widget
{
  get{ return _widget; }
  set{ _widget = value; }

}

Doesn't this seem redundant and a waste of bits?

No one ever calls the private variable directly. You always set it through the property.

Why not just nix it?

Is there dark magic that I am not aware of when using this?

public int widget {get; set;}
M4N
  • 94,805
  • 45
  • 217
  • 260
DotNetRussell
  • 9,716
  • 10
  • 56
  • 111

3 Answers3

3

If you are just looking at the simple example, you're right, it looks like a waste.

BUT... There is more to it.

Here is a great article that goes into much more depth: Why Properties Matter by Stack Overflow legend Jon Skeet.

First of all, it has become a best-practices rule to not expose class fields publicly. You have no control over what happens to he value. But if you use a property instead, you have the ability to add additional logic that happens under the hood as often as needed, without ever changing anything to the public interface of your class. This could be code for handling multiple accesses to limited resources like network/ database, etc. ...

Second, with the version with the backing field you can very easily implement the INotifyPropertyChanged interface for using the values with WPF and the Model-View-ViewModel (MVVM) pattern:

public string FavoriteColor
{
   get
   {
      return this.favoriteColor;
   }

   set
   {
      if (value != this.favoriteColor)
      {
         this.favoriteColor = value;
         if (this.PropertyChanged != null)
         {
            this.PropertyChanged(this, new PropertyChangedEventArgs("FavoriteColor"));
            }
         }
   }
}

(Code snippet taken from Basic MVVM QuickStart)

Third: But if you would ever need to change from a public field to a property - the will get different IL code - You are loosing binary compatibility. This might affect serialization and re-compiling code from other assemblies that access the changed class. This would be bad if you are deploying your application in partial updates where not all assemblies are deployed at the same time.

On the other hand, you can implement properties both with a backing field or as auto-properties, and in both cases you will get the same IL code, which means that you have less risk to break something.

Jens H
  • 4,590
  • 2
  • 25
  • 35
2

Automatic properties (or auto-implemented properties) were not available until C# 3.0.

Maybe one advantage of the first variant (with a backing field) is that you can initialize its value to a non-default value without having to implement a constructor, e.g:

private int _widget = 123;
public int widget
{
  get{ return _widget; }
  set{ _widget = value; }
}
M4N
  • 94,805
  • 45
  • 217
  • 260
0

As @p.s.w.g and @Brandon posted this is a feature added on .Net 3.0 called Auto-Implemented properties, the idea is that you no longer need to declare the private variable in your classes, just the public property and all the required handling to support that is done by the framework.

Back in the old days we were required to write your first example, and I know people who still prefers that way.

You can look it up here: http://msdn.microsoft.com/en-us/library/bb384054.aspx

dacaballero
  • 7
  • 1
  • 2