Geek Answers Handbook

The semantic difference between a property and a field and their consequences

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

Please note that both are private (therefore, they will not be displayed outside this class) and that the property does not use additional verification.

As for semantics, do they have different meanings? In the sense, are they interchangeable when used?

And when it comes to consequences such as (micro?) Performance, it matters if you create a field against a property, that is, letting the compiler take care of the support field for you.

+7
source share
5 answers

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

But basically, private property does not give any advantages (over the field), so why bother?
There is probably (micro) performance. I'm more worried about the extra mess.

+3
source
  • The property contains hiding field data .
  • Private property does not mean much, since anyone who has access to the property will also have access to the field.
  • does not affect performance for the auto-property versus backing field, since the compiler spills out the support field, but there may be serialization / deserialization bindings .

UPDATE

Performance Implications:

There is little performance when using a property (auto or with backing field) vs field, since the property is a method, and the virtcall CLR virtcall be called.

But, as I said, it makes no sense to use a property, and I believe that the field is more readable , as is usually immediately apparent from the naming conclusion (starting with the underscore or camel case).

+3
source

You do not have a link to the property, but you can get a link to the participant. Thus, if you use members, you may need to switch them to properties for some reason later, for example, add a known check.

+1
source

Creating a private automatic property is useless what I see. If it is not automatic, it can be used as a kind of internal event handler to keep the state of the object up-to-date: perform some actions every time the field changes (through the installer) anywhere in the code.

Performance? I don’t think that there will be a problem, even at the micro-micro level.

0
source

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

So, if you have a private property vs private field:

Difference from performance point:

it makes no difference if you use optimization and no trace (properties are treated as inline).

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 the getter and setter. AND MAY use the delegate as ... a delegate, for example, put that delegate in a list with other delegates ( Create a delegate from the getter or setter method) .

Difference from design:

But properties are functions that look like variables. Why do we need functions that look like variables?

Suppose you have a class Hand, and this hand has a variable fingerNumber.

  class Hand { public int fingersNumber; }

Then you can have a lot of code, for example

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

But at some point you may need to add another hand to Hand. Let's say this is ringNumber. And you know that you cannot have more than 10 rings for each finger.

  class Hand { public int fingersNumber; public int ringsNumber; }

now you can’t just do

  leftHand.fingersNumber--

because you have to control the ringNumber on the fingerNumber dependency.

So, you need to create some functions that will check this dependency. You also need to hide the fingers of Number ander ringsNumber from users so that they cannot change these fields without checking.

  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 these functions as

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

The problem here is that the old code leftHand.fingersNumber-- is not working now. And from the very beginning you did not know that rings would be added in the future. To solve problems, it became a paradigm for setting fields as private and using the Set and Get functions to get and change variables and MAKE SURE that in the future you can add any logic there and the code will work!

Setters and Getters are the current situation in C ++, Java, and many languages. But the creators of C # went further and decorated such getters, and the setters function 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 a simple property, and you see an example, these are 5 lines of regular code. So, in some version of C # autoproperties were added to make life easier for programmers. So your class probably looks like

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

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

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

And it DOES NOT BRAKE ANY CODE. how

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

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

Also, as before, simple properties and autoprocessors have the same performance as variables if you use optimization. Se showdown or just google about it.

0
source

More articles:


All Articles