CODEWITHSUNDEEP
c#
joe blogs
joe blogs

Reputation: 142

wpf getters and setters

By what I've read I'm sure I'm going through the same process that most went through when jumping into WPF. I am coming from embedded im struggling.

take these examples

  1. int foo; //

  2. int foo { get; set; } //c#

  3. public int foo{ get => foo; set => foo= value; }

  4. private int _foo;
public int foo{ get => _foo; set => _foo= value; }

Could someone, please give me a definitive answer as to why all the getters and setters.
- is it just a visual studio, and its autocomplete settings?
- is it because of threading and foo is getting marked as volatile behinds the scenes?
- or is something else going on.

Follow up
for anyone learning and struggling with data binding, the links in "580's" reply under "binding" are by far the best examples i have come across, to get your head around the syntax. Also i came across "ReSharper" for visual studio which lets you know about errors and the correct way to fix, using the correct methods. using both the examples and resharper i have learnt more in 3 hrs than i had in the last week.

Upvotes: 1

Views: 4007

Answers (1)

580
580

Reputation: 480

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:

  1. 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?
  2. 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.
  3. 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.
  4. 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

Upvotes: 7

Related Questions