C #4.0 syntactic sugar Article 1: Automatic attributes & amp; implicit types

C #4.0 syntactic sugar Article 1: Automatic attributes & implicit types
Automatic attributes: in C #4.0 and later versions, when the attribute accessors do not need other logic, the automatically implemented attributes make the attribute Declaration more concise. The client code can also create objects through these attributes. Get and set accessors. "id =" mt3 "> as shown in the following example, when declaring an attribute, the compiler creates a private anonymous support field, which can only be accessed through the get and set accessors of the attribute. In the past C #4.0, the attribute of the traditional method was used to encapsulate fields. Here I will briefly compare the differences and associations between the two methods: public class AutoProperty {// traditionally defined attributes must first define fields to encapsulate private string name; public string Name {get {return name ;}set {value = name ;}} // The automatic attribute public string LoginName {get; set ;}} indicates that the traditional method is cumbersome in terms of the number of characters in the code, and the automatic attribute can be implemented by one line of code, so what are the differences between the two functions? Here I use the decompilation tool (The Decompilation tool is used. net Reflector 8.3), the specific effect is as follows: although we write code without writing segments, but the compiler helps us automatically generate fields, after reading the get and set accessors for each attribute, you will find that the traditional pu Blic void set_Name (string value) {value = this. name;} public string get_Name () {return this. name;} // automatic attribute [CompilerGenerated] public void set_LoginName (string value) {this. <LoginName> k _ BackingField = value;} [CompilerGenerated] public string get_LoginName () {return this. <LoginName> k _ BackingField;} note when using automatic attributes: From the code above, we can see that the format of the accesser is similar, that is, the automatic attribute accesser is marked as generated by the compiler, then the field is generated by the compiler. Therefore, the traditional method and automatic attributes have the same effect for compilation, but these tedious operation compilers help us generate the code to reduce the code written by programmers and make the logic of the Code clear, very short. 1. get and set accessors are required for automatically implemented attributes. To make the class unchangeable, declare the set accessors as private. Set accessor, you cannot use an object initializer to initialize the property. "id =" mt5 "> however, when declaring a private set accesser, you cannot use the initial object value to initialize the property. You must use constructors or factory methods. Public string CustomerId {get; private set;} public AutoProperty (string _ CustomerId) {this. customerId = _ CustomerId;} implicit type: You can infer the "type" var rather than the explicit type by assigning a local variable. The var keyword instructs the compiler to deduce the variable type based on the expression on the right of the initialization statement. The inferred type can be a built-in type, anonymous type, user-defined type, or. the type defined in the NET Framework class library, which is defined by Microsoft MSDN. In fact, the simple understanding of implicit type is that programmers can declare variables without specifying the type, and the compiler specifies the type based on the value. 2. If you need to have complex business logic in the attributes, you must use the traditional attributes. No matter what it is, it has its advantages and disadvantages, as long as we make proper use of it. Theoretically speaking, let's directly post the code below: public static void Test () {// traditionally defined variable string CustomerId = "customer"; var NewCustomerId = "implicit type "; var Age = 20; var Array = new string [] {"111", "222"}; object objectstring = "object"; Console. writeLine ("traditional type:" + CustomerId + "" + "implicit type" + NewCustomerId);} from the code above, only the first variable is the display definition variable, some people will see that it is not enough to define the Object directly. What are the advantages of this? I was wondering at the beginning. Later I checked it with The Decompilation tool, here I will map it directly: As can be seen from the above texture, the implicit type will be automatically inferred based on the value on the right after the compiler, but o The bject type is still of the object type after the compiler. Therefore, the binning and unboxing operations will occur, but the implicit type is not of the binning and unboxing operations. Therefore, the implicit type is better than the object type in terms of performance.