In C#, I notice that many coders do something like the following:
class X
{
private int test_;
public int test
{
get { return test_; }
set { if (test_ != value) test_ = value; }
}
}
My question is why keep a private, and a public variable for the same content?
Why did we not do this instead?
class X
{
public int test
{
get; set;
}
}
I mean, we are changing the private variable within anyway. What is the point of not using a single public variable instead?
The code:
class X
{
public int test
{
get; set;
}
}
...is a direct equivalent for this:
class X
{
private int test_;
public int test
{
get { return test_; }
set { test_ = value; }
}
}
The first example is an auto-implemented property. The C# compiler automatically produces the second example when you compile.
Now, the code you presented first though had this line:
set { if (test_ != value) test_ = value; }
You'll notice that it's doing something different to the auto-property equivalent code. And that's where the difference lies in these two approaches.
When you use a backing field for your properties you can introduce specific rules that you need your code to follow.
For example, you might want to set the audio volume on a music app, so your code might be like this:
public class Music
{
private int _volume = 7;
public int Volume
{
get { return _volume; }
set
{
if (value >= 0 && value <= 10)
{
_volume = value;
}
}
}
}
It is common to have a private field variable when your property contains logic like this.
These are not two variables. One is a field and other one is a property. A property is optional getter and setter methods in disguise.
Your proposal of the solution is in fact part of the language, called auto-implemented properties: https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/auto-implemented-properties
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.