java1.8 lambda表达式_java1.8之Lambda表达式

行为参数化

为了应对多变的需求，难道我们就要因为客户每提出一个需求，我们就要写一个方法去实现吗？

显然这样做很冗余，而且维护性大大降低，这说明代码的设计不够好。好在已经有前人帮我们提出了行为参数化思想(即将一段代码逻辑作为参数，使之可以在不同对象间传递)。

java1.8以前使用匿名类来实现行为参数化，即使用匿名类去实现一个函数式接口中的方法。java1.8之后，推出了Lambda表达式来替代以前匿名类实现行为参数化的繁复过程，使代码更简洁、更优雅。

Lambda初体验

先从简单的例子开始：创建一个thread，需要在Thread()构造方法中传入一个Runnable接口的实现类对象，但一般不会为了这个实现类对象去创建一个实现类，java1.8之前更简洁的更便于维护的方式是在构造方法中创建一个实现了Runnable接口的匿名类对象，只使用一次，代码如下：

new Thread(new Runnable() {

@Override

public void run() {

System.out.println("使用匿名类实现Runnable接口，实现功能需要6行代码");

}

}).start();

可以看到，通过匿名类实现Runnable接口，需要编写6行代码，但其实真正实现了我们需要的功能的代码只有一行(黑色加粗)，从代码量上来看，这就显得很冗余，“高度问题(height problem)”。

java1.8发布的新特性，lambda表达式，就可以很好的解决这个问题，下面的代码等价上面的代码：

new Thread(() -> {System.out.println("使用Lambda表达式，只需要一行代码");}).start();

注意上面代码中的红色字体部分，这就是Lambda表达式的一个简单演示，lambda表达式充当了这个接口中的抽象方法的具体实现。

Lambda表达式的语法结构

下面我们就来看一下lambda表达式的几种使用语法：

(params) -> expression

(params) -> statement

(params) -> { statement; }

左边第一个括号中的params参数列表根据需要增加；中间是一个箭头，英文半角的-与大于号>组成，这两个符号之间不能有空格，箭头两边可以有空格；箭头的右边是表达式或者语句块。如果是类似“return a+b”这种结构的方法体，可以直接写成(int a, int b) -> a+b ，expresion能够返回该表达式的结果，可以看到lambda表达式把return这种方法退出语句都简化省略掉了。如果只是想通过控制台输出语句打印一段话，可以写成() -> System.out.println("Hello") 语句末尾的分号都可以省略不写。如果是实现方法的逻辑比较复杂，就可以用花括号将一段逻辑代码括起来，比如 () -> { 语句块 }

函数式接口

在进一步说明lambda表达式之前，先做一个知识储备，什么是函数式接口？

只拥有一个方法的接口，称为函数式接口。在以前的版本中，人们常称这种类型为SAM类型，即单抽象方法类型(SAM，Single Abstract Method)

java1.8之后，设计者们对JDK做了全面的改动，为符合函数式接口规范的接口，都加上了@FunctionalInterface注解，通知编译器这些接口是符合函数式接口的规范，虽然可能有的接口中有多个方法，但是方法的签名可以各有不同。

好像还是不太明白？我们找几个JDK的例子来看看，比如：

(1)Callable接口

@FunctionalInterface

public interface Callable {

V call() throws Exception;

}

(2)Runnable接口

@FunctionalInterface

public interface Runnable {

public abstract void run();

}

(3)java.util.Comparator接口

@FunctionalInterface

public interface Comparator {

int compare(T o1, T o2);

boolean equals(Object obj);

// java1.8之后还增加了一些default方法，这里就不列出

}

可以发现，Callable和Runnable这两个接口的共性，接口中都只声明了一个方法。符合这种结构规范的interface，java中就称之为函数式接口。而在(3)Comparator接口中有两个方法，为什么呢？因为boolean equals(Object obj)是Object类的public方法，函数式接口中允许定义Object的public方法，像clone()方法就不能定义因为是protected方法，加上了@FunctionalInterface注解告诉编译器，这个接口必须符合函数式接口规范的，如果不符合就会编译报凑。

Lambda表达式的结果类型，目标类型(Target Typing)

在初体验的例子中，好像lambda表达式没有结果值类型，但不代表lambda就没有结果类型，只是我们不需要指定lambda表达式的结果类型。

那lambda表达式的结果类型是什么呢？答案是：它的类型是由其上下文推导而来。也就是说，同一段lambda表达式在不同的上下文环境中，可能会有不同的结果类型，比如：

Callable c =() -> "done.";

PrivilegedAction p =() -> "done.";

虽然c和p等号右边的lambda表达式一样，但是两个lambda表达式的结果却不一样，第一个是Callable类型，第二个是PrivilegedAction类型。

由编译器完成对Lambda表达式的结果类型推导，编译器根据Lambda表达式的上下文推导出一个预期的类型，这个预期的类型就是目标类型。lambda表达式对目标类型也有要求，编译器会检查lambda表达式的推导类型和目标类型的方法签名是否一致。需要满足下列全部条件，lambda表达式才可以被赋给目标类型T：

·T 是一个函数式接口

·lambda表达式的参数与 T 中的方法的形参列表在数量、类型上完全一致

·lambda表达式的返回值与 T 中的方法的返回值相兼容，lambda表达式的返回值类型应该是 T 的实现类或子类

·lambda表达式内所抛出的异常与 T 中的方法throws的异常类型相兼容，同上一条

我个人对目标类型的理解：

目标类型不同于返回值类型，它是对要实现的方法所属的函数式接口的一种参考，待实现方法有返回值类型，也有其所属的接口或类，而这个方法所属的接口或类，就是目标类型。

java设计者要求，lambda表达式只能出现在目标类型为函数式接口的上下文中。

代码高度降低了，宽度呢？

lambda表达式将多行代码浓缩到一行，是解决了“高度问题”，但是过多的信息在一行表述，显然会增加lambda表达式一行的代码量，这就产生了“宽度问题”，java设计者在设计lambda表达式时考虑到这一点，做了优化的设计：

(1)省略形参类型

由于目标类型(函数式接口)已经“知道”lambda表达式的形式参数(Formal parameter)类型，所以没有必要把已知类型再重复写一遍。也就是说，lambda表达式的参数类型可以从目标类型中得出。

举个例子：

Comparator c = (s1, s2) -> s1.compareToIgnoreCase(s2);

其中s1和s2我们虽然没有明确指定其参数类型，但是编译器可以通过上下文推导出其形参类型，Comparator接口中有两个方法，int compare(T o1, T o2)、boolean equals(Object obj)，根据lambda表达式的参数列表(2个形参)，可以推导出要实现的接口方法是compare(T o1, T o2)，又根据目标类型Comparator指定了就是，就可以推导出s1和s2的参数类型就是String。

(2)当lambda参数只有一个且其类型可以被推导出时，参数列表的()括号也可以省略

举个例子：

FileFilter java = f -> f.getName().endsWith(".java");

java.io.FileFilter接口中仅有一个方法，boolean accept(File pathname)，可以推导出该lambda表达式的参数列表应该是File类型，也就是说参数f的类型也可以省略了，而且只有这一个参数，那么括号()也可以省略了。

上下文

上面提到很多次lambda表达式只能出现拥有目标类型的上下文中，下面列出带有目标类型的上下文：

·变量声明

·赋值

·返回语句

·数组初始化器

·方法和构造方法的参数

·lambda表达式函数体

·条件表达式(? :)

·转型(Cast)表达式

方法引用

通过上面的例子和说明，我们知道了lambda表达式允许我们自定义一个匿名方法((params) -> {...} 这看起来就像是一个没有名字的方法定义)，并能以函数式接口的方式使用这个匿名方法。那现在我们也可以不用自定义方法，直接引用已有的方法也是可以的，这种引用我们称之为方法引用。

方法引用和lambda表达式拥有相同的特性(例如，都需要一个目标类型，并且需要被转换为函数式接口的实例)，只不过不需要为已有方法提供方法体，我们直接通过该方法的名字就可以引用这个已有方法。

举个例子：

class Person {

private final String name;

public String getName(){

return this.name;

}

....

}

Person[] people = ...

Comparator byName = Comparator.comparing(p - > p.getName());

Arrays.sort(people, byName);

----------------------------------------

加粗部分可以用方法引用lambda表达式来替代：

Comparator byName = Comparator.coparint(Person::getName);

是不是看起来表义就更清晰了呢？方法引用Person::getName就可以看作是lambda表达式p -> p.getName()的一种简写形式，虽然看起来好像代码量没有减少多少，但是拥有了更明确的语义——如果我们想调用的方法拥有一个名字，那我们就直接用这个名字来调用它吧。

方法引用的种类

下面列出方法引用的几种语法：

·静态方法引用ClassName::staticMethodName

·实例中的实例方法引用instanceReferenceName::methodName

·父类上的实例方法引用super::methodName

·本类上的实例方法引用ClassName::methodName

·构造方法引用Class::new

·数组构造方法引用TypeName[]::new

在类型和方法名之间，加上分隔符“::”

用一个例子融会贯通

首先看实例代码：

List people = ... Collections.sort(people,newComparator() {publicintcompare(Person x, Person y) {returnx.getLastName().compareTo(y.getLastName()); } });

看了lambda表达式的用法之后，是不是感觉冗余代码太多呢？

我们先用lambda表达式去掉冗余的匿名类，精简成一行代码：

Collections.sort(people,

(Person x, Person y) -> x.getLastName().compareTo(y.getLastName()));

现在看起来代码是精简了很多，但是感觉抽象程度还比较差，开发人员仍然需要进行实际的比较操作，我们可以借助java.util.Comparator接口中静态方法comparing() (这也是Java1.8新增的)：

Collections.sort(people,

Comparator.comparing((Person p) -> p.getLastName()));

编译器可以帮助我们做类型推导，同时还可以借助静态导入，进一步精简：

Collections.sort(people,comparing(p-> p.getLastName()));

现在看起来，就发现可以将lambda表达式用方法引用来替换：

Collections.sort(people, comparing(Person::getLastName));

使用Collections.sort()的辅助方法也不太妥当，它使代码冗余，也无法针对List接口的数据结构提供特定的高效实现，而且因为Collections.sort()方法不属于List接口，用户在阅读List接口文档的时候可能不会意识到Collections类中有提供一个针对List接口的排序方法sort()，这里可以做一步优化，我们可以为List接口添加一个default方法sort()，然后直接通过List对象调用该sort()方法：

people.sort(comparing(Person::getLastName));

这样即方便调用，也方便代码的阅读和后期维护。将最终结果对比一开始的匿名类的实现方法，是不是要更简短，但语义却更清晰了呢？这就是lambda表达式的好处。