C #: Is it possible to remove "{get; set;}"?

Question

Is there a difference between:

public T RequestedValue { get; set; } 

and

 public T RequestedValue; 

?

Taken from this code:

 public class PropertyChangeRequestEventArgs<T>:EventArgs { public PropertyChangeRequestEventArgs(T pRequestedValue) { RequestedValue = pRequestedValue; } public T RequestedValue { get; set; } } 

Answer 1

The first is an Auto-Implemented Property , the second is a field . Normal Properties expose Getters and Setters, but have a private field to actually store the value:

 private int someProperty; public int SomeProperty { get { return someProperty; } set { someProperty = value; } } 

The first allows you to change some aspects of your class implementation without affecting all other code in your application. The most important point is that with properties, changes can be made without breaking binary compatibility (although a field can often be changed to a property without breaking code). If it is an open member, this property is desirable. (Ruthlessly stealing from Snarfblam's comment)

On the Properties page:

Properties are members that provide a flexible mechanism for reading, writing, or calculating private field values. Properties can be used as if they were public data elements, but in reality they are special methods called accessors. This makes it easy to access data and still helps increase the safety and flexibility of the methods.

Properties using the support field are the most flexible form because they make it easy to implement things like the INotifyPropertyChanged event to update the user interface in Model-View-ViewModel implementations.

Answer 2

deep explanation!

{get; set;} is an automatic property, and the second is a field.

a field is a normal variable of some type that contains data.

a property is several methods (sometimes sometimes it is one), one for get and one for set. they have only syntax similar to fields, but in fact they are completely different.

properties are usually used to filter a set of values ​​or virtualize something in get, etc.

automatic properties, also create a private field behind the scenes, return its value to get and set its value to the set.

this seems like a normal field, but behind the scenes (IL) using properties is completely different from using fields.

  a.Property1 = 4; 

translates into something like:

  a.Set_Propert1(4); 

and this:

 x = a.Property1; 

translates to the following:

 x = a.Get_Property1(); 

So, why is it good practice to use only public properties, even if they are automatic?

let's say that you are writing a library that is being used by another application, and someday you will want to release a new version of this library that restricts one of the fields of your class.

If you use properties, you can simply change the property (even if it is automatic, you can replace it with a full one), and then any application that used your library can still use it in the same way.

but if you created a public field that you now want to limit, you need to create a property for this and make the field private, but if you want, any application that used your library will no longer be used because the way the fields and properties are used is different.

Answer 3

You can write:

 public T RequestedValue { get; set; } 

as a shortcut:

 private T _requestedValue; public T RequestedValue { get { return this._requestedValue; } set { this._requestedValue = value; } } 

They are completely equivalent, also considering performance.

Answer 4

Answer: yes, you can remove {get; set; }, but then subtle differences in loading are added. Some will say that fields and properties express radically different design intentions, but in practice this difference has been destroyed over the years, as C # evolves and gradually erodes syntactic differences.

For a good list of differences between fields and properties in the binary compiler, see the SO difference-between-property-and-field-in-c question. But the answers to this question missed one important point regarding the special role of properties in declaring interfaces.