The get and set syntax in this case indicates what in C# is known as properties. Properties are not specific to WPF, Visual Studio, threading or the volatile keyword. Properties are simply a construct of the C# language. MSDN - Properties
I'm assuming a C/C++ background here if you're coming from the embedded world. Plain old standard member variables in C# are known as fields. Properties represent member variables with a bit of a twist.
Definitive answer on why the get and set keywords are found everywhere is due to their use in properties. Properties are widely used because they are typically considered better practice then using fields in most scenarios. They allow for more fine-grained access control. I would suggest reading through this article by Jon Skeet C# In Depth - Why Properties Matter
Property vs Field
Now for some detail, properties differ from fields in that they may define additional functionality to perform every time a read (get) or modification (set) occur. This functionality happens implicitly such that the consumer of the property may not even be aware of it. This layer of abstraction is one reason why properties have been deemed more valuable then fields.
While not necessarily the case all the time a property typically encapsulates a private field, traditionally of the same type. When the standard syntax { get; set; } is used the compiler will automatically generate a private field of the same type as the property. This is known as an auto property. Example:
public string Title { get; set;}
would be converted into the following by the C# compiler.
private string title;
public string Title
{
get
{
return title;
}
set
{
title = value;
}
}
If you were to manually/explicitly define the private field yourself then the field becomes known as a backing field also sometimes referred to as a backing store. Two of your examples #3 and #4 represent this, where #4 does so more evidently.
As stated earlier not all properties require encapsulating a field. Here is an example of a property that just returns a string literal.
public string RandomText { get { return "Foo"; } }
Now onto your examples:
- Is a private field, private is implicitly stated because when no access modifier is explicitly stated the default is private. MSDN - Access Modifiers. This is not a property, this is a field.
Stack Overflow - What is the difference between a field and a property?
- Is a private property with an equivalent private get and set. The get and set are private because without an explicit access modifier they match the modifier of the property. Note: Get and set cannot be more accessible than the property. Meaning a private property cannot have a public get or public set; same for protected. I'd be willing to state there is little to no value in this specific syntax, but I'm sure someone can prove me otherwise. In this case I would say just use a field.
- Due to the fact that this example uses the field from #1 you're essentially overriding the usage of the default auto-generated field in favor of a backing field.
- This is literally the same thing as #3. What @Sebastian Hofmann meant by it will get compiled into the same Intermediate Language (IL) is that the C# compiler will convert these two examples into the same exact byte code. Wikipedia - Intermediate Language
Binding
MSDN - Data Binding Overview
Helpful reading on data binding. MSDN - Data Binding
