More efficient C # item9: replace out and ref parameters with generic tuples

If we need to return multiple results for a method during design, we usually use the ref or out parameter. At the same time, we still use generic tuples to return multiple irrelevant values.

Let's take a look at the following code, first define a structure with an inheritance relationship.

Code

1 publicclass person
2 {
3 privatereadonlystring m_strname;
4 publicstring name
5 {
6 get {return m_strname ;}
7}
8
9 Public Person (string name)
10 {
11 m_strname = Name;
12}
13
14 publicoverridestring tostring ()
15 {
16 returnstring. Format ("Name: {0}", m_strname );
17}
18}
19
20 publicclass EMPLOYEE: person
21 {
22 privatereadonly decimal m_desalary;
23 public decimal salary
24 {
25 get {return m_desalary ;}
26}
27
28 public employee (string name, decimal salary)
29: Base (name)
30 {
31 m_desalary = salary;
32}
33
34 publicoverridestring tostring ()
35 {
36 returnstring. Format ("Name: {0}, salary: {1}", base. Name, m_desalary );
37}
38}

The following is the test code.

Code

1 privatestaticvoid test ()
2 {
3 employee EMP = new employee ("wing", 1000 );
4 changename (ref EMP, "unknown", 2000 );
5
6 person = new person ("wing ");
7 changename (ref person, "unknown ");
8}
9
10 privatestaticvoid changename (ref employee EMP, string newname, decimal newsalary)
11 {
12 console. writeline (EMP );
13 EMP = new employee (newname, newsalary );
14 console. writeline (EMP );
15}
16
17 privatestaticvoid changename (ref person, string newname)
18 {
19 console. writeline (person );
20 person = new person (newname );
21 console. writeline (person );
22}

Let's take a look at the limitations when using ref and out. First, using the ref parameter makes it difficult to create immutable objects. Second, using the ref parameter makes it difficult to implement polymorphism, because the ref parameter does not support implicit type conversion. For example, in the above Code, we need to define two changname methods. For changname (person), an object of the employee type is passed in. Otherwise, a compilation error is reported.

In fact, the difference between the ref parameter and the return value is that the return value of the method supports implicit type conversion. You can set the return value to the parent type, and then return the child type during actual operation.

So how can we avoid using the ref parameter? We can use tuples, that is, tuple.

We can see the following code.

1 Private Static tuple <string, decimal> getempinfo (employee EMP)
2 {
3 return New tuple <string, decimal> (EMP. Name, EMP. Salary );
4}

Perhaps the above Code only re-adjusts the method signature, but when you gradually become familiar with the use of functional programming structures, you will find the importance of this technology. Methods that accept the out or ref parameters cannot be well combined with other methods, while methods that return a single value (no matter how complicated) can be well combined.

The ref and out parameter table methods can create objects that meet the declared type. polymorphism indicates that the derived class can always replace the base class. However, when a return value object needs to be created in a method, the above statement also contains some new meanings. When the call Code expects a base class object, a derived type object is created in many cases in the method. In general, the above two rules mean that the out and ref parameters cannot really use polymorphism. If you use a wildcard tuples to return multiple values, your algorithm logic will be easier to use.