What are properties for?

See what advantages the property has over the field.

If your property is defined as:

 public int A { get; set; } 

- Of course, there are no immediate benefits. But the benefits will come later.

1. You can hang your logic to write and read the value. Applications can be the sea. For example, you want to count how many times a value is read:

    private int a; private int readcount_a = 0; public int A { get { readcount_a++; return a; } set { a = value; } } 

   You can make a trigger to change the field:

    class Data : INotifyPropertyChanged { public event PropertyChangedEventHandler PropertyChanged; private int a; public int A { get { return a; } set { if (a == value) return; a = value; RaisePropertyChanged(); } } private void RaisePropertyChanged([CallerMemberName] string propertyName = null) { if (PropertyChanged != null) PropertyChanged(this, new PropertyChangedEventArgs(propertyName)); } } 

   You can log all changes to the field:

    public int A { get { return a; } set { Trace.TraceInformation("Changing value of a from {0} to {1}", a, value); a = value; } } 

   You can hang a validation value on writing when writing, or lazy initialization while reading.

    class Data { private string a = null; public string A { get { return a ?? (a = LazyComputeInitialA()); } set { if (value == null) throw new ArgumentException(nameof(A) + " cannot be null", nameof(A)); a = value; } } } 

   In the end, you can not use memory for a value, if in most cases it is the same (as was done with DependencyProperty ):

    class Data { static Dictionary<Data, int> aValues = new Dictionary<Data, int>(); public int A { get { int result; if (aValues.TryGetValue(this, out result)) return result; else return -1; // default value } set { aValues[this] = value; } } } 

2. You want to make different degrees of visibility for the getter and setter, so for example, only your class and its heirs can set the value, and everyone can count. (This is perhaps the best use of the properties for my taste.)

    public int A { get; protected set; } 

3. You may not define a setter at all, and return some value calculated by you:

    public int A { get { return b + c; } } 

   (however, this can be done in the presence of a setter). For example, you can provide data in different formats:

    public double Radians { get; set; } public double Degrees { get { return Radians * 180.0 / Math.PI; } set { Radians = value * Math.PI / 180.0; } } 

4. You can set a breakpoint to write or read properties! Breakpoints to write or read data in the Visual Studio managed code debugger until (at least until the current version of Visual Studio 2017, version 15.7) are not supported .

5. You can set the presence of a property in the interface, as opposed to the field:

    interface ISupportsA { int A { get; } } class Data : ISupportsA { public int A { get; set; } } 

6. You can declare the property virtual! That is, you can redefine the behavior of a property in inherited classes. Try to do this with a field.

7. Properties are not worse than fields in the sense that you can make a property work like this is just a field ( public int A { get; set; } ), but you cannot make a field work as a property. That is, it is almost always better to “set out” to expose a property, rather than a field.

8. XML serialization and WPF-ovsky Binding only works with properties, but not with fields. Yes, this can be considered a mistake in the framework, but in fact it is.

But aren't the properties in the language superfluous? It seems that instead of a property, you can simply define two functions:

 class Data { private int a; public int GetA() { return a; } public int SetA(int a) { this.a = a; } } 

The answer is that.

First, one property instead of two functions is a logical group. In a good language, you say what you think. In fact, you provide the user with a “variable” A with additional, often invisible semantics from the outside. It means that it should look like one variable, so that users of the class think in the same terms as you.

Secondly, it is the readability of the text. Compare the code with the properties:

 player.car.speed++; 

and without them:

 getPlayer().getCar().setSpeed(getPlayer().getCar().getSpeed()+1); 

What is easier to perceive?

In fairness, you need to note the disadvantages of the properties compared to the fields.

1. Properties cannot be used as out / ref parameter, fields are possible.

2. Access to the fields is very fast, but access to the properties can be slow if the code inside the getter / setter is slow. However, a slow setter or (even worse) getter is considered a bad practice, it is recommended to avoid them, so as not to destroy the mental model “variable with a small addition”.

3. Access to a property can throw an exception or hang, while simpler fields behave extremely simply. Of course, a correctly written property will not hang, and I would recommend throwing out exceptions only in cases when a class user violated a contract for access to a field.

Another subtle difference between the property and the field is that the getter returns you a copy of the value, while working with the field you access the variable directly. When working with fields of reference types (that is, the type of which is a class), there is no practical difference, since working with an object from a copy of a link does not differ from working from the original link. There is a difference, however, when the field is a variable structure (although, in themselves, variable structures are a bad idea ). An example of a case where this is important is in the code snippet below.

It is often believed that you can first declare the data as a field, and then, if necessary, “turn” it into a property. This is only partly true : in this case, you lose binary compatibility. The code that your class used must be recompiled, since at the level of the compiled code, accessing the field and the property is not the same thing. In addition, the meaning of the code may change, leading to subtle errors. Example from the article on the link above:

 using System; struct MutableStruct { public int Value { get; set; } public void SetValue(int newValue) { Value = newValue; } } class MutableStructHolder { public MutableStruct Field; public MutableStruct Property { get; set; } } class Test { static void Main(string[] args) { MutableStructHolder holder = new MutableStructHolder(); // Меняет значение holder.Field holder.Field.SetValue(10); // Получает *копию* holder.Property и изменяет её holder.Property.SetValue(10); Console.WriteLine(holder.Field.Value); // 10 Console.WriteLine(holder.Property.Value); // 0 } } 

By the way, according to Wikipedia , the getter and setter correctly name the accessor and mutator, respectively. Did you know about this? [Although MSDN simply writes “ access methods .”]