C#夯实基础-Lambda在List中的使用

在C#中基本类型比如List ,Dictionary，数组等都有委托来实现相关的 *** 作。此时Lambda表达式就可以使用了.

代码

查询当前List每项包含o字符的所有项

在List这个基本类型有一个方法FindAll的基本方法

可以发现FindAll中使用了一个委托

参数 match 是一个 Predicate 委托，用于定义要搜索的元素应满足的条件。

Predicate是返回bool型的一个委托

最终的代码是

返回的结果是:

同样的方法，我们可以查看比如List的其他使用了委托的方法，都可以使用Lambda表达式来对List进行 *** 作。

其他的方法，可以参考MSDN或者在当前的List的Find方法F1进行C#本身已经定义的方法参数

List.Find查找一个元素

List.Sort排序方法

另外说明一下，委托的作用就是将实现交给用户 ，本身只是起到一个关键返回结果的的作用，根据返回结果，对象根据结果进行相应的调整。

主要有三个优势。其一是无需管理服务器，Amazon Lambda可以自动运行用户的代码，无需预置或管理服务器。用户只需编写代码并将其上传至Lambda。其二是持续扩展，Amazon Lambda通过运行代码以响应每个触发程序，从而实现自动扩展用户的应用程序。用户的代码将并行运行并独立处理每个触发程序，使其按照工作负载的大小精密扩展。其三是带来亚秒级计量，使用Amazon Lambda时，会按代码执行时间（以每1毫秒为单位）和代码触发次数收费。代码未运行时，无需支付任何费用。

为了支持函数式编程，Java 8引入了Lambda表达式.

在Java 8中采用的是内部类来实现Lambda表达式.具体实现代码,可以通过debug看, 同时通过字节码查看工具及反编译工具来验证.

自从lambda表达式成为Java语言的一部分之后，Java集合（Collections）API就面临着大幅变化。而JSR 355（规定了Java lambda表达式的标准）的正式启用更是使得Java集合API变的过时不堪。

尽管我们可以从头实现一个新的集合框架（比如“Collection II”），但取代现有的集合框架是一项非常艰难的工作，因为集合接口渗透了Java生态系统的每个角落，将它们一一换成新类库需要相当长的时间。因此，我们决定采取演化的策略（而非推倒重来）以改进集合API： 为现有的接口（例如Collection，List和Stream）增加扩展方法；

在类库中增加新的流（stream，即java.util.stream.Stream）抽象以便进行聚集（aggregation） *** 作；

改造现有的类型使之可以提供流视图（stream view）；

改造现有的类型使之可以容易的使用新的编程模式，这样用户就不必抛弃使用以久的类库，例如ArrayList和HashMap

（当然这并不是说集合API会常驻永存，毕竟集合API在设计之初并没有考虑到lambda表达式。我们可能会在未来的JDK中添加一个更现代的集合类库）。

除了上面的改进，还有一项重要工作就是提供更加易用的并行（Parallelism）库。尽管Java平台已经对并行和并发提供了强有力的支持，然而开发者在实际工作（将串行代码并行化）中仍然会碰到很多问题。因此，我们希望Java类库能够既便于编写串行代码也便于编写并行代码，因此我们把编程的重点从具体执行细节（how computation should be formed）转移到抽象执行步骤（what computation should be perfomed）。

---