Lambda表达式及其优势

忘是亡心i 2022-09-19 00:25 146阅读 0赞

# .NET 3.5中委托的写法（**Lambda表达式**） #

**Lambda表达式**在C\#中的写法是“*arg-list* => *expr-body*”，“=>”符号左边为表达式的参数列表，右边则是表达式体（body）。参数列表可以包含0到多个参数，参数之间使用逗号分割。例如，以下便是一个使用**Lambda表达式**定义了委托的示例1：

Func<int, int, int> max = (int a, int b) =>
    {
        if (a > b)
        {
            return a;
        }
        else
        {
            return b;
        }
    };

与上文使用delegate定义匿名方法的作用相同，**Lambda表达式**的作用也是为了定义一个匿名方法。因此，下面使用delegate的代码和上面是等价的：

Func<int, int, int> max = delegate(int a, int b)
    {
        if (a > b)
        {
            return a;
        }
        else
        {
            return b;
        }
    };

那么您可能就会问，这样看来**Lambda表达式**又有什么意义呢？**Lambda表达式**的意义便是它可以写的非常简单，例如之前的**Lambda表达式**可以简写成这样：

Func<int, int, int> max = (a, b) =>
    {
        if (a > b)
        {
            return a;
        }
        else
        {
            return b;
        }
    };

由于我们已经注明max的类型是Func<int, int, int>，因此C\#编译器可以明确地知道a和b都是int类型，于是我们就可以省下参数之前的类型信息。这个特性叫做“[类型推演][Link 1]”，也就是指编译器可以自动知道某些成员的类型2。请不要轻易认为这个小小的改进意义不大，事实上，您会发现**Lambda表达式**的优势都是由这一点一滴的细节构成的。那么我们再来一次改变：

Func<int, int, int> max = (a, b) => a > b ? a : b;

如果**Lambda表达式**的body是一个表达式（expression），而不是语句（statement）的话，那么它的body就可以省略大括号和return关键字。此外，如果**Lambda表达式**只包含一个参数的话，则参数列表的括号也可以省略，如下：

Func<int, bool> positive = a => a > 0;

如今的写法是不是非常简单？那么我们来看看，如果是使用delegate关键字来创建的话会成为什么样子：

Func<int, bool> positive = delegate(int a)
    {
        return a > 0;
    };

您马上就可以意识到，这一行和多行的区别，这几个关键字和括号的省略，会使得编程世界一下子变得大为不同。

当然，**Lambda表达式**也并不是可以完全替代delegate写法，例如带ref和out关键字的匿名方法，就必须使用.NET 2.0中的delegate才能构造出来了。

# 使用示例一 #

**Lambda表达式**的增强在于“语义”二字。“语义”是指代码所表现出来的含义，说的更通俗一些，便是指一段代码给阅读者的“感觉”如何。为了说明这个例子，我们还是使用示例来说明问题。

第一个例子是这样的：“请写一个方法，输入一个表示整型的字符串列表，并返回一个列表，包含其中偶数的平方，并且需要按照平方后的结果排序”。很简单，不是吗？相信您一定可以一蹴而就：

static List<int> GetSquaresOfPositive(List<string> strList)
    {
        List<int> intList = new List<int>();
        foreach (var s in strList) intList.Add(Int32.Parse(s));
    
        List<int> evenList = new List<int>();
        foreach (int i in intList)
        {
            if (i % 2 == 0) evenList.Add(i);
        }
    
        List<int> squareList = new List<int>();
        foreach (int i in evenList) squareList.Add(i * i);
    
        squareList.Sort();
        return squareList;
    }

我想问一下，这段代码给您的感觉是什么？它给我的感觉是：做了很多事情。有哪些呢？

1.  新建一个整数列表intList，把参数strList中所有元素转化为整型保存起来。
2.  新建一个整数列表evenList，把intList中的偶数保存起来。
3.  新建一个整数列表squareList，把evenList中所有数字的平方保存起来。
4.  将squareList排序。
5.  返回squareList。

您可能会问：“当然如此，还能怎么样？”。事实上，如果使用了**Lambda表达式**，代码就简单多了：

static List<int> GetSquaresOfPositiveByLambda(List<string> strList)
    {
        return strList
            .Select(s => Int32.Parse(s)) // 转成整数
            .Where(i => i % 2 == 0) // 找出所有偶数
            .Select(i => i * i) // 算出每个数的平方
            .OrderBy(i => i) // 按照元素自身排序
            .ToList(); // 构造一个List
    }

配合.NET 3.5中定义的扩展方法，这段代码可谓“一气呵成”（在实际编码过程中，老赵更倾向于把这种简短的“递进式”代码写作一行）。那么这行代码的“语义”又有什么变化呢？在这里，“语义”的变化在于代码的关注点从“怎么做”变成了“做什么”。这就是**Lambda表达式**的优势。

在第一个方法中，我们构造了多个容器，然后做一些转化，过滤，并且向容器填充内容。其实这些都是“怎么做”，也就是所谓的“how (to do)”。但是这些代码并不能直接表示我们想要做的事情，我们想要做的事情其实是“得到XXX”，“筛选出YYY”，而不是“创建容器”，“添加元素”等操作。

在使用**Lambda表达式**的实现中，代码变得“声明式（declarative）”了许多。所谓“声明式”，便是“声称代码在做什么”，而不像“命令式（imperative）”的代码在“操作代码怎么做”。换句话说，“声明式”关注的是“做什么”，是指“what (to do)”。上面这段声明式的代码，其语义则变成了：

1.  把字符串转化为整数
2.  筛选出所有偶数
3.  把每个偶数平方一下
4.  按照平方结果自身排序 
5.  生成一个列表

至于其中具体是怎么实现的，有没有构造新的容器，又是怎么向容器里添加元素的……这些细节，使用**Lambda表达式**的代码一概不会关心——这又不是我们想要做的事情，为什么要关心它呢？

虽然扩展方法功不可没，但我认为，**Lambda表达式**在这里的重要程度尤胜前者，因为它负责了最关键的“语义”。试想，“i => i \* i”给您的感觉是什么呢？是构造了一个委托吗（当然，您一定知道在这里其实构造了一个匿名方法）？至少对我来说，它的含义是“把i变成i \* i”；同样，“i => i % 2 == 0”给我的感觉是“（筛选标准为）i模2等于零”，而不是“构造一个委托，XXX时返回true，否则返回false”；更有趣的是，OrderBy(i => i)给我的感觉是“把i按照i自身排序”，而不是“一个返回i自身的委托”。这一切，都是在“声明”这段代码在“做什么”，而不是“怎么做”。

没错，“类型推演”，“省略括号”和“省略return关键字”可能的确都是些“细小”的功能，但也正是这些细微之处带来了编码方式上的关键性改变。

# 使用示例二 #

使用**Lambda表达式**还可以节省许多代码（相信您从第一个示例中也可以看出来了）。不过我认为，最省代码的部分更应该可能是其“分组”和“字典转化”等功能。因此，我们来看第二个示例。

这个示例可能更加贴近现实。不知您是否关注过某些书籍后面的“索引”，它其实就是“列出所有的关键字，根据其首字母进行分组，并且要求对每组内部的关键字进行排序”。简单说来，我们需要的其实是这么一个方法：

static Dictionary<char, List<string>> GetIndex(IEnumerable<string> keywords) { ... }

想想看，您会怎么做？其实不难（作为示例，我们这里只关注小写英文，也不关心重复关键字这种特殊情况）：

static Dictionary<char, List<string>> GetIndex(IEnumerable<string> keywords)
    {
        // 定义字典
        var result = new Dictionary<char, List<string>>();
    
        // 填充字典
        foreach (var kw in keywords)
        {
            var firstChar = kw[0];
            List<string> groupKeywords;
    
            if (!result.TryGetValue(firstChar, out groupKeywords))
            {
                groupKeywords = new List<string>();
                result.Add(firstChar, groupKeywords);
            }
    
            groupKeywords.Add(kw);
        }
    
        // 为每个分组排序
        foreach (var groupKeywords in result.Values)
        {
            groupKeywords.Sort();
        }
    
        return result;
    }

那么如果利用**Lambda表达式**及.NET框架中定义的扩展方法，代码又会变成什么样呢？请看：

static Dictionary<char, List<string>> GetIndexByLambda(IEnumerable<string> keywords)
    {
        return keywords
            .GroupBy(k => k[0]) // 按照首字母分组
            .ToDictionary( // 构造字典
                g => g.Key, // 以每组的Key作为键
                g => g.OrderBy(k => k).ToList()); // 对每组排序并生成列表
    }

光从代码数量上来看，前者便是后者的好几倍。而有关“声明式”，“what”等可读性方面的优势就不再重复了，个人认为它比上一个例子给人的“震撼”有过之而无不及。

试想，如果我们把GetIndexByLambda方法中的**Lambda表达式**改成.NET 2.0中delegate形式的写法：

static Dictionary<char, List<string>> GetIndexByDelegate(IEnumerable<string> keywords)
    {
        return keywords
            .GroupBy(delegate(string k) { return k[0]; })
            .ToDictionary(
                delegate(IGrouping<char, string> g) { return g.Key; },
                delegate(IGrouping<char, string> g)
                {
                    return g.OrderBy(delegate(string s) { return s; }).ToList();
                });
    }

您愿意编写这样的代码吗？

因此，**Lambda表达式**在这里还是起着决定性的作用。事实上正是因为有了**Lambda表达式**，.NET中的一些函数式编程特性才被真正推广开来。“语言特性”决定“编程方式”的确非常有道理。这一点上Java是一个很好的反例：从理论上说，Java也有“内联”的写法，但是C\#的使用快感在Java那边还只能是个梦。试想GetIndexByLambda在Java中会是什么情况3：

public Dictionary<Char, List<String>> GetIndexInJava(Enumerable<String> keywords)
    {
        return keywords
            .GroupBy(
                new Func<String, Char> {
                    public Char execute(String s) { return s.charAt(0); }
                })
            .ToDictionary(
                new Func<Grouping<Char, String>, Char> {
                    public Char execute(IGrouping<Char, String> g) { return g.getKey(); }
                },
                new Func<Grouping<Char, String>, List<string>> {
                    public List<String> execute(IGrouping<Char, String> g)
                    {
                        return g
                            .OrderBy(
                                new Func<String, String> {
                                    public String execute(String s) { return s; }
                                })
                            .ToList();
                    }
                });
    }

一股[语法噪音][Link 2]的气息扑面而来，让人无法抵挡。由于Java中的匿名类型语法（即上面这种内联写法）连类型信息（new Func<String, Char>\{ ... \}这样的代码）都无法省去，因此给人非常繁琐的感觉。面对这样的代码，您可能会有和我一样的想法：“还不如最普通的写法啊”。没错，这种函数式编程的风格，由于缺乏语言特性支持，实在不适合在Java语言中使用。事实上，这种内联写法很早就出现了（至少在02、03年我还在使用Java的时候就已经有了），但是那么多年下来一点改进都没有。而**Lambda表达式**出现之后，社区中立即跟进了大量项目，如[Moq][]，[Fluent NHibernate][]等等，充分运用了C\# 3.0的这一新特性。难道这还不够说明问题吗？

对了，再次推荐一下[Scala语言][Scala]，它的代码可以写的和C\#一样漂亮。我不是Java平台的粉丝，更是Java语言的忠实反对者，但是我对Java平台上的Scala语言和开源项目都抱有强烈的好感。

既然谈到了函数式编程，那么就顺便再多说几句。其实这两个例子都有浓厚的函数式编程影子在里面，例如，对于函数试编程来说，Where常被叫做filter，Select常被叫做map。而.NET 3.5中定义的另一些方法在函数式编程里都有体现（如Aggregate相当于fold）。如果您对这方面感兴趣，可以关注[Matthew Poswysocki][]提出的[Functional C\#][Functional C]类库。

# 总结 #

既可以提高可读性，又能够减少代码数量，我实在找不出任何理由拒绝**Lambda表达式**。

哦，对了，您可能会提到“性能”，这的确也是一个重要的方面，不过关于这个话题我们下次再谈。受篇幅限制，原本计划的“上”“下”两篇这次又不得不拆开了。至于其他的内容，也等讨论完性能问题之后再说吧。

当然，世界上没有东西是完美的，如果您觉得**Lambda表达式**在某些时候会给您带来“危害”，那么也不妨使用delegate代替**Lambda表达式**。例如，为了代码清晰，在某些时候还是显式地指明参数类型比较好。不过对我而言，在任何情况下我都会使用**Lambda表达式**——最多使用“(int a, string b) =>”的形式咯，我想总比“delegate(int a, string b)”要统一、省事一些吧。

[Link 1]: http://en.wikipedia.org/wiki/Type_inference
[Link 2]: http://martinfowler.com/bliki/SyntacticNoise.html
[Moq]: http://code.google.com/p/moq
[Fluent NHibernate]: http://www.fluentnhibernate.org/
[Scala]: http://www.scala-lang.org/
[Matthew Poswysocki]: http://codebetter.com/blogs/matthew.podwysocki/default.aspx
[Functional C]: http://code.msdn.microsoft.com/FunctionalCSharp