C# 7.0 新特性1： 基于Tuple的“多”返回值方法

回顾

首先，提出一个问题，C#中，如何使一个方法可返回"多个"返回值？

我们先来回顾一下C#6.0 及更早版本的做法。

在C#中，通常我们有以下4种方式使一个方法返回多条数据。

• 使用 KeyValue 组合
  •  View Code
• 使用 ref/out 参数
  • Ref
  •  View Code
  • Out
  •  View Code
• 使用 struct 或者 class
  • struct
  •  View Code
  • class
  •  View Code
  • dynamic
  •  View Code
• 使用 Tuple
•  View Code

Okay, 回顾的废话有些多了。我们来看看C#7.0中的写法

新特性（C#7.0）

老规矩，先上代码

 1 static void Main(string[] args)
 2 {
 3     int int1 = 25;
 4     int int2 = 28;
 5     var result = Add_Multiply(int1, int2);
 6     Console.WriteLine($"Add: {result.add}, Multiply: {result.multiply}");
 7     //(var add, var multiply) = Add_Multiply(int1, int2);
 8     //Console.WriteLine($"Add: {add}, Multiply: {multiply}");
 9 }
10 public (int add, int multiply) Add_Multiply(int int1, int int2) 
11     => (int1 + int2, int1 * int2);

怎么样？比起6.0及以前的C#，有没有一种非常清爽的感觉。

其实只是基于Tuple 做了语法简化的语法糖罢了，只是给人一种多个返回值的错觉。

总结

这个特性虽然不是多么振奋人心的变化，但是解决了之前很多码农的一些痒点。

1. 看看KeyValue对的方式，本来很简单的一个操作，写出来的代码会显得非常的笨拙，取值的时候又根据Key获取。而且，最重要的是，如果不在运行时，外面调用的代码是不知道有那些Key的。

2. 再说Ref/Out，这种方式应该是传统意义上最流行的写法了。甚至C#7.0的该特性，也无法取缔ref在一定情景下的性质。但至少在ref用于返回值这种情况下，代码体现出的风格明显是和实际逻辑不符合的，明明是返回值，却要以参数的形式进出，非常不合理。

3. struct和class的方式就不多说了，如果你针对的是一个实体，还能讲得通，但如果本身目的是返回多个相关性不大的数据，专门为方法间传递而加一个本没有用处的Model类或结构，只能说是当时解决方案下的无奈。dynamic虽然从表现形式上没有这种问题，但是存在更坑的问题是，除非在运行时，否则外部调用代码根本不知道方法里传出来什么。

4. 说到传统的Tuple，其实是和该特性最接近的了，但是看看调用时的*.Item1，*.Item2 。。天知道都是何物。即使在实现方法里，也让人面对这种只见类型不见实际意义的值表示一头雾水。