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 。。天知道都是何物。即使在实现方法里，也让人面对这种只见类型不见实际意义的值表示一头雾水。