157 suggestions for writing high-quality code to improve the C # program [do not select List & lt; T & gt; as the base class, the iterator is read-only, and the Set writable attribute is used with caution]

This article has been updated to http://www.cnblogs.com/aehyok/p/3624579.html. This article mainly records the following content:

23. Avoid using List as the base class of the custom collection class.

Recommendation 24. The iterator should be read-only.

25. Exercise caution when performing write operations on set attributes.

If you want to implement a custom collection class, it is best not to use List <T> as the base class, but to extend the corresponding generic interface, generally, it is a sub-interface of Ienumerable <T> and ICollection <T> (or ICollection <T>, such as IList <T>.

  Employee1:List<Employee>

  Employee2:IEnumerable<Employee>,ICollection<Employee>

However, it is a pity that the inherited List <T> does not bring any inheritance advantages. Instead, it loses the flexibility brought about by interface-Oriented Programming and may not be noticed, hidden bugs will come one after another.

Let's take a look at Employee1 as an example. If you want to Add a change to the Add method

       Name { ; 

      Employee1:List<Employee>  += 

Call

           Main(=  Employee(){Name= Employee(){Name= Employee(){Name=<Employee> employees = Employee(){Name= ( item 

This turns out to be the case.

How can we avoid such errors? Now let's take a look at the implementation method of employee 2.

      Employee2:IEnumerable<Employee>,ICollection<Employee><Employee> items =  List<Employee> IEnumerator<Employee>    }

This call is okay.

           Main(=  Employee(){Name= Employee(){Name= Employee(){Name=<Employee> employees = Employee() { Name =  ( item 

Running result

When implementing the iterator at the front-end time, I found this problem. In the iterator, only the GetEnumeratior method is used, and the SetEnumerator method is not used. All sets do not have a writable iterator attribute. The original reasons for this roommate are as follows:

1. This violates the open and closed principles in the design model. Iterations set to the set may directly cause exceptions or changes to the set's behavior. Once a new iteration requirement is required, you can create a new iterator to meet the requirement, instead of setting the iterator for the set, this will directly cause unknown behavior in other iteration scenarios that use the set object.

Second: now we have LINQ. Using LINQ, you can meet any iteration requirements without creating any new types.

About how to implement the iterator can be read by my post http://www.cnblogs.com/aehyok/p/3642103.html

Now suppose there is a public set object, and there are two business classes that need to operate on this set object. Business class A is only responsible for iterative display of elements:

            IMyEnumerable list = ==

Business class B needs to implement a new iterator for the set object out of its own needs, so it performs the following operations:

            MyEnumerator2 enumerator2 = =

The key to the problem is that, now we will go back to business class A to execute an iteration display, and the result will be the iterator set by B to complete the output. This is equivalent to BG interfering with A's behavior without notifying A. This should be avoided.

Therefore, do not set writable attributes for the iterator.

If a set attribute exists in a type attribute, ensure that the attribute object is generated by the type. Setting the attribute to writable increases the chance of throwing an exception. Generally, if the set property has no value, the return value of Count is 0 instead of null. Let's look at a simple piece of code:

       Name { ;   Age { ;   List<Student> Students { ;  List<Student> list =  List<Student> Student(){Name=,Age= Student(){Name=,Age=  Main(= =  Thread(() =>=+=  Thread(() =>= 

First, an error is reported.

The problem with this Code is that thread t1 will assign a value to the Students attribute of the StudentTeamA type, which is a readable/writable attribute. Because the set property is a reference type, there are currently two references to this property object, that is, the set itself and the caller's Type Variable list.

Thread t2 may be written by another program, but it only shows list. As a result, the modification to list directly affects the objects in another worker thread. In this example, the list Value is null, simulating that the set attribute is changed to null without the knowledge of StudentTeamA (or worker thread t1. Then, thread t1 simulates several operations on the Students attribute, resulting in an exception throw.

Next, let's make a simple modification to the above Code. First, set the set attribute of the type to read-only. Second, the set object is created by the type itself, this ensures that the Set property always has only one reference:

       Name { ;   Age { ;   List<Student> Students { ; =  List<Student> StudentTeamA(IEnumerable<Student> list): List<Student> list =  List<Student> Student(){Name=,Age= Student(){Name=,Age=  Main(=  Student() { Name=, Age=            StudentTeamA teamB = 

After the modification, StudentTemaA will find the following problems by trying to assign values to the attribute Students.

We also found two methods to initialize the set.

Tips for English

1. I have an outing plan tommorrow. -- I have a walking plan tomorrow.

2. Amazing -- make ...... Surprising unbelievable-incredible

3. blue sky and white beach-blue sky and white clouds

4. Could you please show me the way to cinema? -- Can you show me the way to the cinema?

5. go straight -- go straight to turn left -- turn left at the first cross -- at the first intersection

Author: aehyok

Source: http://www.cnblogs.com/aehyok/

Thank you for reading this article. If you are interested in the content described in my blog, please make a suggestion. Thank you for your support:-O.