行為參數化

為了應對多變的需求，難道我們就要因為客戶每提出一個需求，我們就要寫一個方法去實現嗎？

顯然這樣做很冗余，而且維護性大大降低，這說明代碼的設計不夠好。好在已經有前人幫我們提出了行為參數化思想（即將一段代碼邏輯作為參數，使之可以在不同對象間傳遞）。

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表達式的好處。