Android lambda表达式笔记（二）

关于
本文介绍了Java SE 8中新引入的lambda语言特性以及这些特性背后的设计思想。这些特性包括：

lambda表达式（又被成为“闭包”或“匿名方法”）
方法引用和构造方法引用
扩展的目标类型和类型推导
接口中的默认方法和静态方法
1. 背景
Java是一门面向对象编程语言。面向对象编程语言和函数式编程语言中的基本元素（Basic Values）都可以动态封装程序行为：面向对象编程语言使用带有方法的对象封装行为，函数式编程语言使用函数封装行为。但这个相同点并不明显，因为Java的对象往往比较“重量级”：实例化一个类型往往会涉及不同的类，并需要初始化类里的字段和方法。

不过有些Java对象只是对单个函数的封装。例如下面这个典型用例：Java API中定义了一个接口（一般被称为回调接口），用户通过提供这个接口的实例来传入指定行为，例如：

public interface ActionListener {
void actionPerformed(ActionEvent e);
}
这里并不需要专门定义一个类来实现ActionListener接口，因为它只会在调用处被使用一次。用户一般会使用匿名类型把行为内联（inline）：

button.addActionListener(new ActionListener) {
public void actionPerformed(ActionEvent e) {
ui.dazzle(e.getModifiers());
}
}
很多库都依赖于上面的模式。对于并行API更是如此，因为我们需要把待执行的代码提供给并行API，并行编程是一个非常值得研究的领域，因为在这里摩尔定律得到了重生：尽管我们没有更快的CPU核心（core），但是我们有更多的CPU核心。而串行API就只能使用有限的计算能力。

随着回调模式和函数式编程风格的日益流行，我们需要在Java中提供一种尽可能轻量级的将代码封装为数据（Model code as data）的方法。匿名内部类并不是一个好的选择，因为：

语法过于冗余
匿名类中的this和变量名容易使人产生误解
类型载入和实例创建语义不够灵活
无法捕获非final的局部变量
无法对控制流进行抽象
上面的多数问题均在Java SE 8中得以解决：

通过提供更简洁的语法和局部作用域规则，Java SE 8彻底解决了问题1和问题2
通过提供更加灵活而且便于优化的表达式语义，Java SE 8绕开了问题3
通过允许编译器推断变量的“常量性”（finality），Java SE 8减轻了问题4带来的困扰
不过，Java SE 8的目标并非解决所有上述问题。因此捕获可变变量（问题4）和非局部控制流（问题5）并不在Java SE 8的范畴之内。（尽管我们可能会在未来提供对这些特性的支持）

1. 函数式接口（Functional interfaces）
   尽管匿名内部类有着种种限制和问题，但是它有一个良好的特性，它和Java类型系统结合的十分紧密：每一个函数对象都对应一个接口类型。之所以说这个特性是良好的，是因为：

接口是Java类型系统的一部分
接口天然就拥有其运行时表示（Runtime representation）
接口可以通过Javadoc注释来表达一些非正式的协定（contract），例如，通过注释说明该操作应可交换（commutative）
上面提到的ActionListener接口只有一个方法，大多数回调接口都拥有这个特征：比如Runnable接口和Comparator接口。我们把这些只拥有一个方法的接口称为函数式接口。（之前它们被称为SAM类型，即单抽象方法类型（Single Abstract Method））

我们并不需要额外的工作来声明一个接口是函数式接口：编译器会根据接口的结构自行判断（判断过程并非简单的对接口方法计数：一个接口可能冗余的定义了一个Object已经提供的方法，比如toString()，或者定义了静态方法或默认方法，这些都不属于函数式接口方法的范畴）。不过API作者们可以通过@FunctionalInterface注解来显式指定一个接口是函数式接口（以避免无意声明了一个符合函数式标准的接口），加上这个注解之后，编译器就会验证该接口是否满足函数式接口的要求。

实现函数式类型的另一种方式是引入一个全新的结构化函数类型，我们也称其为“箭头”类型。例如，一个接收String和Object并返回int的函数类型可以被表示为(String, Object) -> int。我们仔细考虑了这个方式，但出于下面的原因，最终将其否定：

它会为Java类型系统引入额外的复杂度，并带来结构类型（Structural Type）和指名类型（Nominal Type）的混用。（Java几乎全部使用指名类型）
它会导致类库风格的分歧——一些类库会继续使用回调接口，而另一些类库会使用结构化函数类型
它的语法会变得十分笨拙，尤其在包含受检异常（checked exception）之后
每个函数类型很难拥有其运行时表示，这意味着开发者会受到类型擦除（erasure）的困扰和局限。比如说，我们无法对方法m(T->U)和m(X->Y)进行重载（Overload）
所以我们选择了“使用已知类型”这条路——因为现有的类库大量使用了函数式接口，通过沿用这种模式，我们使得现有类库能够直接使用lambda表达式。例如下面是Java SE 7中已经存在的函数式接口：

java.lang.Runnable
java.util.concurrent.Callable
java.security.PrivilegedAction
java.util.Comparator
java.io.FileFilter
java.beans.PropertyChangeListener
除此之外，Java SE 8中增加了一个新的包：java.util.function，它里面包含了常用的函数式接口，例如：

Predicate——接收T对象并返回boolean
Consumer——接收T对象，不返回值
Function