Reputation: 107950

The semantic difference between a property and a field, and their implications

Take private string Property {get; set;} versus private string field.

Note that both are private (so they will not be exposed outside of this class) and that the property is not employing extra validation.

As regards semantics, do they have different meanings? In the sense that, are they interchangeable when used like this?

And when it comes to implications, such as (micro?) performance, does it matter if you create a field versus a property i.e. letting the compiler take care of the backing field for you.

Upvotes: 7

Answers (5)

Dmitry Romanov

Reputation: 14090

Properties ARE functions.
Fields are 'variables with at least class visibility'.

So if you have private property vs private field:

The difference from the performance point:

no difference if you use optimization and no trace (properties are treated as inlines).

The difference in semantics:

1) Formally no difference.
2) More deeply, there IS a difference. Since properties are functions you CAN get a delegate from getter and setter. And CAN use the delegate as... delegate, like putting this delegate to the list with other delegates (Create a delegate from a property getter or setter method)

The difference from a design view:

But properties are functions that looks like variables. Why one could need functions that look like variables?

Lets say you have class Hand and this hand has variable fingersNumber.

 class Hand
 {
     public int fingersNumber;
 }

Then you may have a lot of code like

 if(he is BadPerson) leftHand.fingersNumber--
 if(doctor.Heal()) leftHand.fingersNumber++

But at some point you may want to add some other variable to Hand. Lets say it is ringsNumber. And you know, that you can't have more than 10 rings for each finger.

 class Hand
 {
     public int fingersNumber;
     public int ringsNumber;

 }

now, you cannot just do

 leftHand.fingersNumber--

because you have to control ringsNumber on fingersNumber dependence.

So you have to create some functions that whould check this dependance. Also you have to hide fingersNumber ander ringsNumber from users so they cannot change this fields without the check.

 class Hand
 {
     private int fingersNumber;
     private int ringsNumber; 
     public int GetFingersNumber(){...check logic...}
     public void SetFingersNumber(int value){...check logic...}
     public int GetRingsNumber(){...check logic...}
     public void SetRingsNumber(int value){...check logic...}
 }

And use this functions as

 if(he is BadPerson) leftHand.SetFingersNumber(leftHand.GetFingersNumber()-1)

The problem here that the old code leftHand.fingersNumber-- would not work now. And from the beginning you wouldn't know that one will add rings in the future. To solve the problems it became a paradigm to set fields as private and use Set and Get functions to get and change variables and BE SURE that in the future one could add any logic there and code would work!

Setters and Getters is a current situation in C++, Java and many languages. But C# creators went further and decorated such getters and setters functions as "properties".

 class Hand
 {
     private int fingersNumber; 
     public int FingersNumber
     {
          get{return fingersNumber;}
          set{fingersNumber=value;}
     }
     ...     
  }
  ...
  if(he is BadPerson) leftHand.FingersNumber--;

But most of the time people create such simple property and, you see the example, it is 5 lines of routine code. So at some version of C# autoproperties was added to simplify life of programmers. So your class is probably looks like

 class Hand
 {
     public int FingersNumber{get;set;}
 }

but at any time you can extend this get set behaviour:

  class Hand
 {
     private int fingersNumber; 
     public int FingersNumber
     {
          get{...check logic...}
          set{...check logic...}
     }

     ...     
  }

And it will NOT BRAKE ANY CODE. Like

  if(he is BadPerson) leftHand.FingersNumber--;

So thats what are the properties, why do they used and what is the difference with fields.

Also as I ser earlier, simple properties and autoproperties have the same performance as variables if you use optimization. Se disassembly or just google about it.

Upvotes: 0

Aliostad

Reputation: 81660

A property is about data hiding of a field
A private property does not mean much, since whoever has access to the property, will have access to the field as well
There is no performance implication for auto-property versus backing field since compiler spits out the backing field but there can be serialisation/deserialisation caveats.

UPDATE

Performance implications:

There is a slight performance in using property (auto or with backing field) vs field since a property is a method and a CLR virtcall needs to be called.

But as I said, there is not much point in using property and I believe a field is more readable as usually immediately visible by the naming convention (starting with underscore or camel casing).

Upvotes: 3

vines

Reputation: 5225

You can't have a reference to a property, but you can get a reference to a member. Thus, if you use members, you might have trouble switching them to properties for whatever reason later, such as adding the notorious validation.

Upvotes: 1

InBetween

Reputation: 32740

Creating a private automatic property has no use that I can see. If its not automatic it could be used as some kind of internal 'event handler' to keep the object state up to date: perform some actions every time the field changes (through the setter) anywhere in the code.

Performance? I dont think there would be an issue, not even at a micro micro level.

Upvotes: 0

Henk Holterman

Reputation: 273179

When they're private the only difference I know is that the property is not suitable for out and ref parameters.

But mostly a private property does not deliver any advantages (over a field), so why bother?
There probably are (micro) performance costs. I would worry more about the extra clutter.