行為參數(shù)化

為了應(yīng)對(duì)多變的需求，難道我們就要因?yàn)榭蛻裘刻岢鲆粋€(gè)需求，我們就要寫一個(gè)方法去實(shí)現(xiàn)嗎？

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

java1.8以前使用匿名類來實(shí)現(xiàn)行為參數(shù)化，即使用匿名類去實(shí)現(xiàn)一個(gè)函數(shù)式接口中的方法。java1.8之后，推出了Lambda表達(dá)式來替代以前匿名類實(shí)現(xiàn)行為參數(shù)化的繁復(fù)過程，使代碼更簡潔、更優(yōu)雅。

Lambda初體驗(yàn)

先從簡單的例子開始：創(chuàng)建一個(gè)thread，需要在Thread()構(gòu)造方法中傳入一個(gè)Runnable接口的實(shí)現(xiàn)類對(duì)象，但一般不會(huì)為了這個(gè)實(shí)現(xiàn)類對(duì)象去創(chuàng)建一個(gè)實(shí)現(xiàn)類，java1.8之前更簡潔的更便于維護(hù)的方式是在構(gòu)造方法中創(chuàng)建一個(gè)實(shí)現(xiàn)了Runnable接口的匿名類對(duì)象，只使用一次，代碼如下：

new Thread(new Runnable() {

@Override

public void run() {

System.out.println("使用匿名類實(shí)現(xiàn)Runnable接口，實(shí)現(xiàn)功能需要6行代碼");

}

}).start();

可以看到，通過匿名類實(shí)現(xiàn)Runnable接口，需要編寫6行代碼，但其實(shí)真正實(shí)現(xiàn)了我們需要的功能的代碼只有一行(黑色加粗)，從代碼量上來看，這就顯得很冗余，“高度問題(height problem)”。

java1.8發(fā)布的新特性，lambda表達(dá)式，就可以很好的解決這個(gè)問題，下面的代碼等價(jià)上面的代碼：

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

注意上面代碼中的紅色字體部分，這就是Lambda表達(dá)式的一個(gè)簡單演示，lambda表達(dá)式充當(dāng)了這個(gè)接口中的抽象方法的具體實(shí)現(xiàn)。

Lambda表達(dá)式的語法結(jié)構(gòu)

下面我們就來看一下lambda表達(dá)式的幾種使用語法：

(params) -> expression

(params) -> statement

(params) -> { statement; }

左邊第一個(gè)括號(hào)中的params參數(shù)列表根據(jù)需要增加；中間是一個(gè)箭頭，英文半角的-與大于號(hào)>組成，這兩個(gè)符號(hào)之間不能有空格，箭頭兩邊可以有空格；箭頭的右邊是表達(dá)式或者語句塊。如果是類似“return a+b”這種結(jié)構(gòu)的方法體，可以直接寫成(int a, int b) -> a+b ，expresion能夠返回該表達(dá)式的結(jié)果，可以看到lambda表達(dá)式把return這種方法退出語句都簡化省略掉了。如果只是想通過控制臺(tái)輸出語句打印一段話，可以寫成() -> System.out.println("Hello") 語句末尾的分號(hào)都可以省略不寫。如果是實(shí)現(xiàn)方法的邏輯比較復(fù)雜，就可以用花括號(hào)將一段邏輯代碼括起來，比如 () -> { 語句塊 }

函數(shù)式接口

在進(jìn)一步說明lambda表達(dá)式之前，先做一個(gè)知識(shí)儲(chǔ)備，什么是函數(shù)式接口？

只擁有一個(gè)方法的接口，稱為函數(shù)式接口。在以前的版本中，人們常稱這種類型為SAM類型，即單抽象方法類型(SAM，Single Abstract Method)

java1.8之后，設(shè)計(jì)者們對(duì)JDK做了全面的改動(dòng)，為符合函數(shù)式接口規(guī)范的接口，都加上了@FunctionalInterface注解，通知編譯器這些接口是符合函數(shù)式接口的規(guī)范，雖然可能有的接口中有多個(gè)方法，但是方法的簽名可以各有不同。

好像還是不太明白？我們找?guī)讉€(gè)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方法，這里就不列出

}

可以發(fā)現(xiàn)，Callable和Runnable這兩個(gè)接口的共性，接口中都只聲明了一個(gè)方法。符合這種結(jié)構(gòu)規(guī)范的interface，java中就稱之為函數(shù)式接口。而在(3)Comparator接口中有兩個(gè)方法，為什么呢？因?yàn)閎oolean equals(Object obj)是Object類的public方法，函數(shù)式接口中允許定義Object的public方法，像clone()方法就不能定義因?yàn)槭莗rotected方法，加上了@FunctionalInterface注解告訴編譯器，這個(gè)接口必須符合函數(shù)式接口規(guī)范的，如果不符合就會(huì)編譯報(bào)湊。

Lambda表達(dá)式的結(jié)果類型，目標(biāo)類型(Target Typing)

在初體驗(yàn)的例子中，好像lambda表達(dá)式?jīng)]有結(jié)果值類型，但不代表lambda就沒有結(jié)果類型，只是我們不需要指定lambda表達(dá)式的結(jié)果類型。

那lambda表達(dá)式的結(jié)果類型是什么呢？答案是：它的類型是由其上下文推導(dǎo)而來。也就是說，同一段lambda表達(dá)式在不同的上下文環(huán)境中，可能會(huì)有不同的結(jié)果類型，比如：

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

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

雖然c和p等號(hào)右邊的lambda表達(dá)式一樣，但是兩個(gè)lambda表達(dá)式的結(jié)果卻不一樣，第一個(gè)是Callable類型，第二個(gè)是PrivilegedAction類型。

由編譯器完成對(duì)Lambda表達(dá)式的結(jié)果類型推導(dǎo)，編譯器根據(jù)Lambda表達(dá)式的上下文推導(dǎo)出一個(gè)預(yù)期的類型，這個(gè)預(yù)期的類型就是目標(biāo)類型。lambda表達(dá)式對(duì)目標(biāo)類型也有要求，編譯器會(huì)檢查lambda表達(dá)式的推導(dǎo)類型和目標(biāo)類型的方法簽名是否一致。需要滿足下列全部條件，lambda表達(dá)式才可以被賦給目標(biāo)類型T：

·T 是一個(gè)函數(shù)式接口

·lambda表達(dá)式的參數(shù)與 T 中的方法的形參列表在數(shù)量、類型上完全一致

·lambda表達(dá)式的返回值與 T 中的方法的返回值相兼容，lambda表達(dá)式的返回值類型應(yīng)該是 T 的實(shí)現(xiàn)類或子類

·lambda表達(dá)式內(nèi)所拋出的異常與 T 中的方法throws的異常類型相兼容，同上一條

我個(gè)人對(duì)目標(biāo)類型的理解：

目標(biāo)類型不同于返回值類型，它是對(duì)要實(shí)現(xiàn)的方法所屬的函數(shù)式接口的一種參考，待實(shí)現(xiàn)方法有返回值類型，也有其所屬的接口或類，而這個(gè)方法所屬的接口或類，就是目標(biāo)類型。

java設(shè)計(jì)者要求，lambda表達(dá)式只能出現(xiàn)在目標(biāo)類型為函數(shù)式接口的上下文中。

代碼高度降低了，寬度呢？

lambda表達(dá)式將多行代碼濃縮到一行，是解決了“高度問題”，但是過多的信息在一行表述，顯然會(huì)增加lambda表達(dá)式一行的代碼量，這就產(chǎn)生了“寬度問題”，java設(shè)計(jì)者在設(shè)計(jì)lambda表達(dá)式時(shí)考慮到這一點(diǎn)，做了優(yōu)化的設(shè)計(jì)：

(1)省略形參類型

由于目標(biāo)類型(函數(shù)式接口)已經(jīng)“知道”lambda表達(dá)式的形式參數(shù)(Formal parameter)類型，所以沒有必要把已知類型再重復(fù)寫一遍。也就是說，lambda表達(dá)式的參數(shù)類型可以從目標(biāo)類型中得出。

舉個(gè)例子：

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

其中s1和s2我們雖然沒有明確指定其參數(shù)類型，但是編譯器可以通過上下文推導(dǎo)出其形參類型，Comparator接口中有兩個(gè)方法，int compare(T o1, T o2)、boolean equals(Object obj)，根據(jù)lambda表達(dá)式的參數(shù)列表(2個(gè)形參)，可以推導(dǎo)出要實(shí)現(xiàn)的接口方法是compare(T o1, T o2)，又根據(jù)目標(biāo)類型Comparator指定了就是，就可以推導(dǎo)出s1和s2的參數(shù)類型就是String。

(2)當(dāng)lambda參數(shù)只有一個(gè)且其類型可以被推導(dǎo)出時(shí)，參數(shù)列表的()括號(hào)也可以省略

舉個(gè)例子：

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

java.io.FileFilter接口中僅有一個(gè)方法，boolean accept(File pathname)，可以推導(dǎo)出該lambda表達(dá)式的參數(shù)列表應(yīng)該是File類型，也就是說參數(shù)f的類型也可以省略了，而且只有這一個(gè)參數(shù)，那么括號(hào)()也可以省略了。

上下文

上面提到很多次lambda表達(dá)式只能出現(xiàn)擁有目標(biāo)類型的上下文中，下面列出帶有目標(biāo)類型的上下文：

·變量聲明

·賦值

·返回語句

·數(shù)組初始化器

·方法和構(gòu)造方法的參數(shù)

·lambda表達(dá)式函數(shù)體

·條件表達(dá)式(? :)

·轉(zhuǎn)型(Cast)表達(dá)式

方法引用

通過上面的例子和說明，我們知道了lambda表達(dá)式允許我們自定義一個(gè)匿名方法((params) -> {...} 這看起來就像是一個(gè)沒有名字的方法定義)，并能以函數(shù)式接口的方式使用這個(gè)匿名方法。那現(xiàn)在我們也可以不用自定義方法，直接引用已有的方法也是可以的，這種引用我們稱之為方法引用。

方法引用和lambda表達(dá)式擁有相同的特性(例如，都需要一個(gè)目標(biāo)類型，并且需要被轉(zhuǎn)換為函數(shù)式接口的實(shí)例)，只不過不需要為已有方法提供方法體，我們直接通過該方法的名字就可以引用這個(gè)已有方法。

舉個(gè)例子：

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表達(dá)式來替代：

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

是不是看起來表義就更清晰了呢？方法引用Person::getName就可以看作是lambda表達(dá)式p -> p.getName()的一種簡寫形式，雖然看起來好像代碼量沒有減少多少，但是擁有了更明確的語義——如果我們想調(diào)用的方法擁有一個(gè)名字，那我們就直接用這個(gè)名字來調(diào)用它吧。

方法引用的種類

下面列出方法引用的幾種語法：

·靜態(tài)方法引用ClassName::staticMethodName

·實(shí)例中的實(shí)例方法引用instanceReferenceName::methodName

·父類上的實(shí)例方法引用super::methodName

·本類上的實(shí)例方法引用ClassName::methodName

·構(gòu)造方法引用Class::new

·數(shù)組構(gòu)造方法引用TypeName[]::new

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

用一個(gè)例子融會(huì)貫通

首先看實(shí)例代碼：

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

看了lambda表達(dá)式的用法之后，是不是感覺冗余代碼太多呢？

我們先用lambda表達(dá)式去掉冗余的匿名類，精簡成一行代碼：

Collections.sort(people,

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

現(xiàn)在看起來代碼是精簡了很多，但是感覺抽象程度還比較差，開發(fā)人員仍然需要進(jìn)行實(shí)際的比較操作，我們可以借助java.util.Comparator接口中靜態(tài)方法comparing() (這也是Java1.8新增的)：

Collections.sort(people,

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

編譯器可以幫助我們做類型推導(dǎo)，同時(shí)還可以借助靜態(tài)導(dǎo)入，進(jìn)一步精簡：

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

現(xiàn)在看起來，就發(fā)現(xiàn)可以將lambda表達(dá)式用方法引用來替換：

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

使用Collections.sort()的輔助方法也不太妥當(dāng)，它使代碼冗余，也無法針對(duì)List接口的數(shù)據(jù)結(jié)構(gòu)提供特定的高效實(shí)現(xiàn)，而且因?yàn)镃ollections.sort()方法不屬于List接口，用戶在閱讀List接口文檔的時(shí)候可能不會(huì)意識(shí)到Collections類中有提供一個(gè)針對(duì)List接口的排序方法sort()，這里可以做一步優(yōu)化，我們可以為List接口添加一個(gè)default方法sort()，然后直接通過List對(duì)象調(diào)用該sort()方法：

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

這樣即方便調(diào)用，也方便代碼的閱讀和后期維護(hù)。將最終結(jié)果對(duì)比一開始的匿名類的實(shí)現(xiàn)方法，是不是要更簡短，但語義卻更清晰了呢？這就是lambda表達(dá)式的好處。

總結(jié)

以上是生活随笔為你收集整理的java1.8 lambda表达式_java1.8之Lambda表达式的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。