Get and set accessors in C #

When learning the attributes of C # syntax, we must first deal with get and set accessors, and understand what get should be obtained in English literally, set should be set, so let's take a look at how the official website defines the accessors:Get is the operation to read the attribute, and set is the operation to set the attribute. Define an attribute. If only get is available, this attribute is read-only. Similarly, only set attributes are written only. Of course, only set attributes are meaningless.

Next, we will use some code instances to get in touch with get and set accessors.

Class bank {private int money; // Private field public int money // attribute {// get accessors, which can be understood as an alternative method, returns the private variable money get {return money;} // set accessors that have been assigned a value, assign the value we entered to the private variable money set {money = value ;}}}

 

For example:

The money attribute is like an ATM in a bank. You can't see the money in it, but you can use set to save money and get to get money ). Money is a private field and is encapsulated in a class. Programs other than the class cannot directly access it. The set and get members of the class are the only method for internal attributes of the external program category, just as if you go to the bank to get the money, you can't get the money directly from the bank's safe, but the bank's business staff get the money for you.
So how can we use the money attribute ??

 

Class program {static void main (string [] ARGs) {// instantiate a bank Bank = New Bank (); // assign values to the money attribute, in this case, we access the set accesser bank. money = 15; // perform the value operation on the money attribute. In this case, we access the get accesser int A = Bank. money ;}}

Careful friends can find that when we set the breakpoint in the Set access and execute the code bank. Money = 15;, it will enter the set accesser in our properties.

 

These are the most basic applications of our set and get accessors.

But why should we use get and set accessors ??
Using get and set to read and write the public variable money is actually indirectly changing the value of the money private variable. Why does the instance directly perform read/write operations on money without the value of public? Are we doing this?

In fact, I was familiar with get and set at the beginning, not to say that their meaning is hard to understand, but why? Why not use a public field variable instead?

Understanding 1: Get and set are used to increase the value assignment and value restriction.

 

Class bank {private int money; // Private field public int money // attribute {// get accessors, which can be understood as an alternative method, return the private variable money get {return money;} // set accessors that have been assigned a value, assign the value we entered to the private variable money, and add restrictions, A negative set {If (value >=0) {money = value ;}else {money = 0 ;}} cannot be saved ;}}}}

In this case, we will never be able to assign negative values to the money attribute!

In fact, this type of application is very common in our actual projects! Example:

 

Public String applystaff {// delayed loading applystaff object get {If (this. isghost) {lazyloaderfactory. getloader (). loadapplicationconfirm (this);} return applystaff;} set {// judge the length of the input character if (value. length> 40) {Throw new exception ("the recipient cannot exceed 40 characters. ") ;}This. applystaff = value ;}}

 

Public String billname {get {return billname;} set {If (value = string. empty) {Throw new exception ("the document name cannot be blank");} else if (value. length> 40) {Throw new exception ("the document name cannot exceed 40 characters");} else {This. billname = value ;}}}

If you set some features of this attribute in the Set accessors, such as the value cannot be blank, length, numbers, regular expressions, and so on, and then throw an exception, the presentation layer will accept it again, in this way, you can write less verification programs.

Understanding 2: encapsulation, security, and integrity

I didn't think too clearly.