Summary: .NET attributes get & set
"Effective C #" Article 1: instead of using the property accessible data members
Conclusion : As long as the data is going to be exposed in a public interface or type of protected interface, we should use the property to achieve. For the type or having the sequence of dictionary feature, indexer should be employed. All members should always declared as private . (If you are familiar attribute syntax, remember this conclusion on it) a , property (property) and data members basic syntax:
public class Customer
...{
private string _name; public string Name2; public string Name
...{ get ...{ return _name;
} set ...{ if (( value == null ) || ( value.Length == 0 )) throw new ArgumentException( "Name cannot be blank", "Name" ); _name = value; } } // ……
}
//进程调用Customer customerOne = new Customer();customerOne.Name = "This Company, Inc."; //属性设置customerOne.Name2 = "This Company, Inc."; //数据成员设置string name = customerOne.Name;//属性获取string name2 = customerOne.Name2; // get the data members
The syntax can be seen from the above properties and data members in the use of the same, but by definition there are still a lot of difference;
Second, property advantages :
1, can obtain better binding data support; the data can not members
2, can be more easily make any change to its realization in the future access method;
3, can more easily be limiting on the property business logic;
four,
Performance comparison of properties and data members：
Almost no differencereference : http://blog.csdn.net/hy_lihuan/archive/2007/12/25/1967228.aspx
Research on early learning .NET, often met with some learning C # /. NET's friend asked, what to attribute this fancy stuff to do? Later, when do the project also received a team of people often complain of back, why not just put a public field? Such as: class Card
{
public String the Name;
}
and do a private field + public property Card class
{
private String name;
public String the Name
{
GET this.name {return;}
SET = {this.name value;}
}
}
I I remember in the early years of a project, team of a friend or even tired to write private field + public property, in particular, hit a lot of bloated data object class time, simply wrote a small tool to provide a class the field names and types, and then automatically generate the appropriate private field + public property class.
When I was in the program design is complete pragmatist, with a slightly elegant little words called "excessive do not like the design." If you really write like that above Card, and there needs to be any changes in the future, I do not like programs like paragraph 2 above as deliberately made things complicated. However, if the component point of view, there are always some class to long for external use, there are also potentially needs to be changed in the future. At this time, it is very necessary to provide property.
This is the Item trying to generalize the use of property reasons:
1. The check can be done on assignment, or additional processing
2. Thread Synchronization can be done
3. virtual property may be used, or abstract properties
4. The properties may be placed in the interface
with different access rights can be provided 5. get-only or set-only version, or even to the read, write (C # 2.0 support)
personal feeling 3,4 bar is an attribute of the biggest advantages can fill the deficiency is not "empty field" or "abstract fields", and is very useful in the design of components, but also reflects the C # such a component-oriented language spiritual connotation.
But without these reasons, and in the future the possibility of big changes for the program is relatively small, I think no need to try to turn each field must become public property. For example, in the design of some lightweight struct, for interworking when the direct use public fields nothing wrong. So, Mr. Bill Wagner feel this entry using "Always Use Properties Instead of Accessible Data Members" seems too tough.
In fact, this discussion also showed the need to pay attention when reading "Effective C #", a book that is Effective principle is not universal. Different projects (component-based, high degree of reuse project? Or "write once, N years have run" project), different roles (library / component developers? Or application developers?), Has a different the Effective guidelines. In fact, many of the book Items are from the perspective of library / component developers to consider.
Performance issues on the property need to talk a little, if only to simply access mode to use the property, to a certain extent, there is no loss of performance. Because the JIT compilation process has already done a deal with the inline. However, there are some basic inline processing conditions, the JIT compiler in some cases not inline, such as a virtual call, IL The method of the code length is too long (more than the current predetermined 32bytes CLR the code length is too long), the complex control flow logic, there is exception handling. These conditions are either did not use inline (such as virtual property), or inline too costly, easily lead to code bloat, either inline up time-consuming - has lost inline significance because inline mechanism for .NET It occurred in the JIT process. Use attribute individual feels uncomfortable place, such as it affects developer productivity, but does not affect the efficiency of the code to run.
Discernment value types and reference types of use cases
are discussed in terms of this type of design time tradeoff-- is designed for the type of structure or class. Mr. Bill Wagner gives a principle "value type is used to store data type used to define the behavior of the reference (value types store values and reference types define behavior)".
How to determine the applicability of this principle, Bill Wagner also gives a method that first answer the following questions:
whether the main responsibility 1. The type used for data storage?
2. Does the type of public interfaces are some access to property?
3. Is convinced that there can never be the type subclass?
4. Is convinced of this type can never have polymorphic behavior?
If the answer to all questions is yes, then you should use a numeric type. This judgment does have good reason to support, but I personally think that "these four questions the answer is yes" also does not constitute the whole reason for the use of numeric types. Because in practice many projects, I found to bring the value type performance problems can not be discounted. Numerical performance problems caused by two main types:
1. Since the conversion between a numerical example of the type of the managed heap and stack caused box / unbox, managed heap and the resulting waste.
Type using the default value is 2. The value of copy semantics, if the type value is relatively large, when the transfer parameters and function return values, it will cause performance problems.
On Article 1, Bill Wagner referred to the "reference type will burden garbage collector" in the Terms of this seemingly correct judgment. However, due to the effect box / unbox, and in some cases, but rather the type of value to the garbage collector brings more burden. For example some types of values into a set, and then read and write them frequently. If that happens, I want to "give up the use of class structure" might be a better approach. In fact, a numeric type as a data storage (such as the System.Drawing.Point) was added to a collection (The System.Collections.ArrayList) is a very common operation, however. However, C # 2.0 generic technologies newly introduced great improvements to the problem box / unbox of.
On Article 2, Mr Scott Meyers Effective C ++ in Article 22 "to make use of pass-by-reference (transfer site), less pass-by-value (by value)" in speaking more clearly. Although the structure of type C # has a default deep copy semantics, no copy call to the constructor. But there is no structure type subclass, and therefore do not have the polymorphism some extent, there is no cutting (slicing) that can occur when the value of C ++ objects pass effect. But the cost value of the copy is still not small. Especially in this type of value is relatively large, the problem is more serious. In fact, the .NET Framework Design Guidelines for Class Library Developers document, in the description of what type of structure should be used when time, which refers to a principle (also some parallel principle) - the size of the type of instance data you want less than 16 bytes. The document is mainly from the type of operating efficiency levels to be considered, and Mr. Bill Wagner terms here are mainly from the type of design levels to consider.
From the above discussion of two of view, I tend to take a more conservative design strategies to structure type. For the class can actively boldly use. Because "the type of structure designed to improperly class" adverse consequences is much less than "inappropriately designed for the class structure type" the adverse consequences. On the current experience, I even think that only the circumstances and unmanaged interoperability deal is the most abundant type of structural reasons, other cases should "think twice." Of course, after the C # 2.0 introduced generics, box / unbox will no longer be a heavy burden, meet some very featherweight occasions, the type of structure still has its own place.
http://www.uml.org.cn/net/200608211.htm
ref :http://www.cnblogs.com/pandengfeng/articles/618510.html
Original: Large column [C #] .NET get and set properties