explain public variable ; (vs) public variable {get; set;} difference in C#?

Question

Similar questions has been asked a lot but it still doesn't make sense to me as I am beginner.

here is the link

What is the { get; set; } syntax in C#?

As that answer states (I will be using age instead of "name" to avoid confusion)

Case 1

public class Genre
{
    public int Age { get; set; }
}

and

Case 2:

public class Genre
{
  private int age;
  public int Age
  {
      get
      {
          return this.age;
      }
      set
      {
          this.age = value;
      }
  }

}

Both are the same things.

So for Case 1, where is private age variable?

Does it get declared in the backend.

If Yes, then what name will be assign to it?

Surely not (Age => age) Right?

It feels like,

public int Age { get; set; }

// is same thing as

public int Age;

Now, people have mentioned that one is property another is field. But they both can be used in similar way. So what is the difference on application level?

Can you please give me an example?

Answer 1

It feels like,

public int Age { get; set; }

is same thing as

public int Age;

Absolutely not, the first one is two functions, the setter and the getter, while the second one is a field, an integer. As a physical example of the difference, you can do ref Age in the second example, since it has a physical location in memory, but not in the first example, since it's just functions, it's code.

So for Case 1, where is private age variable? Does it get declared in the backend. If Yes, then what name will be assign to it?

Yeah, it gets generated for you by the compiler with a name you can't declare in C# because it contains invalid characters (that are valid in .Net in general). The actual name doesn't matter, just know that you can't possibly use it or collide with it.

Answer 2

There is no difference when you use them as simple variables but using a variable as property gives you the ability to perform a check or create an event handler. For example:

private int _onetoten;
public int OneToTen
    {
        get => _onetoten;
        set
        {
            if ((value > 0) && (value < 11))
            {
                _onetoten = value;
            }
        }
    }

Answer 3

The main difference between the two members in your last code snippet is encapsulation

See the "Encapsulation" part on this page: https://learn.microsoft.com/en-us/dotnet/csharp/fundamentals/tutorials/oop

Hiding the internal state and functionality of an object and only allowing access through a public set of functions.

You asked about what private field gets generated if you use an automatic property. In fact the compiler will generate a private backing field usually called something like k__BackingField or similar.

For example, I created a basic class as follows:

public class Dog
{
    public string Name { get; set; }
}

This definitely creates a field in the background, and I can find out by using ILSpy to decompile it and we see the following:

Notice the Name property is there as you'd expect, with its getter and setter. But notice also the k__BackingField.

When we inspect it, it is comprised of the following code:

[CompilerGenerated]
[DebuggerBrowsable(DebuggerBrowsableState.Never)]
private string <Name>k__BackingField;

So we can see that there is definitely a private field in the background being generated for the property. We can also confirm that it actually uses that field by inspecting the get_Name getter on the Name property:

[CompilerGenerated]
{
    return <Name>k__BackingField;
}

The getter for the Name property indeed returns the private field that was compiler generated for us.

I think what you're stuck on is why we would do this. Basically, if you simply have a public field on a class, you're giving permission for all-and-any other classes to set and get that field without any kind of checks or balances or rules about what goes on when setting or retrieving that value. For small applications that aren't very complex, this won't create an issue for you. But in the future when you're writing bigger applications or libraries, when you want to guarantee certain functionality behaves the same way all the time, this best practice will be necessary.