Using automatic implementation properties in Visual Studio 2010

In previous versions of 2010, you would need to use the Get function if you wanted to obtain the properties of an object. Similarly, if you want to set the properties of an object, you need to take a set function. Although these operations are not very difficult, they need to be used frequently in application development. As a result of this accumulation, the workload will increase a lot. In 2010, there has been no small improvement. The main purpose is to adopt the feature of "automatically implement attributes".

I. The connotation of automatic realization of attributes

As the name suggests, automatic implementation of properties is to automate the management of attributes. Simply put, an automatic implementation attribute can help developers quickly specify an object's properties (generally referred to as a class) without having to write code to perform a get or set operation on the property. It should be noted, however, that this does not mean that the system is no longer performing a get or a set operation. Instead, the system automatically associates get and set procedures when writing code for automatically implemented properties. That doesn't need to be implemented by code, but in the background, the system is still automatically implemented by invoking the set and get functions. This developer needs special attention.

It is also worth mentioning that, in addition to automatically associating set and get procedures, VisualStudio2010 automatically creates a private field to store variables for this property. This means that you can manage this property at the code level. If you can declare a property that contains a default value in a line of code files, and so on. This greatly increases the flexibility of "automatically implement properties".

Second, to prevent the name of the support field conflicts with other objects

In this part of the story, the author said that the editor will also automatically create a private field to store this "auto implementation Properties" of the variable. So how is this automatically created field named? Typically, in the process of defining an automatically implemented property (in VB, for example), the system automatically creates a hidden private field to contain the value of this property. This field is also called "Support fields." Since it's a field, you need to have a name. The name is automatically defined by the system. The rule that is defined is to precede the name of the automatically implemented property with an underscore. If you have a field named name now. The developer declares "auto implement properties" for this field, and the name of the support field that the compiler automatically creates is _name.

Notice here that if the object of this maze is already in this project, such as the name of the class member, and so on, then a naming conflict will result, causing the compilation to fail. As far as I know, there are some developers who prefer to use the symbol "-". For some test or temporary classes, prefer the "_" underscore sign to begin with. If you have this habit, you need to pay special attention to this naming conflict in the use of automatic implementation properties.

Characteristics and access of supporting fields

Although self-sustaining fields are created automatically by the system compiler and are a hidden field, developers can still access this field if necessary. For this reason, some of the characteristics of this field developers need to know, otherwise, this field can not be used properly.

According to the author test and understand, this field mainly has the following several characteristics.

The first is that access rights are independent of the field itself, that is, the access modifier for this supported field is always not private. Take the name of the field above as an example. Perhaps the name of the field itself takes the modifier public. However, the access modifier for this _name support field is private. That is, regardless of what modifiers are used in the field of name, the modifiers for the corresponding self-sustaining field are private. This limits the permissions that it accesses. Typically, this modifier does not allow changes, nor does it suggest changes.

The second is on the shared settings, two fields are the same setting. If this field is now named, and the property is marked as share, the supported field properties for this field are also shared. This is just the opposite of the modifier above. In general, these default settings are not recommended by the author for subsequent changes.

The third is to note that it is possible that the developer has set some special properties on the Name field. such as read-only or some other special properties. However, it should be noted that the values of these special properties are not automatically passed to the support field. So the name field is still quite different from its corresponding support field. You need to be aware of these differences when you visit. Otherwise, it is likely to run into a wall.

So what is the form of access to this support field? The approach that I suggest is accessed through code. That is, you can access the support field in your code as you would access the other fields (note the limitations mentioned above). This approach is preferred. Second, you can access them through debugging tools such as monitoring Windows. There are a number of developers who might like to use Intellisentse to manage fields at ordinary times. It should be noted, however, that the supported fields are typically not displayed in the Intellisentse text completion list.