在過(guò)去的幾年中，我一直使用Java 8 進(jìn)行了很多的編碼工作，用于開發(fā)新應(yīng)用和遷移遺留應(yīng)用，我覺(jué)得是時(shí)候?qū)懸恍┯杏玫摹弊罴褜?shí)踐”。我個(gè)人不喜歡”最佳實(shí)踐”這個(gè)術(shù)語(yǔ)，因?yàn)樗馕吨耙坏肚小钡慕鉀Q方案，當(dāng)然編碼工作是不會(huì)這樣的–這是因?yàn)槲覀冮_發(fā)人員會(huì)想出適合我們的方案。但我發(fā)現(xiàn)我對(duì)Java8特別的喜歡，它讓我的生活更輕松一點(diǎn)，所以我想就此話題展開討論。

Optional

Optional 是一個(gè)被嚴(yán)重低估的功能, 它消除了很多困擾著我們的 NullPointerExceptions。它在代碼邊界（包括你調(diào)用和提供 API）處理上特別有用，因?yàn)樗试S你和你調(diào)用的代碼說(shuō)明程序運(yùn)行的期望結(jié)果。

然而，如果沒(méi)有必要的思考和設(shè)計(jì)，那么就會(huì)導(dǎo)致一個(gè)小變化而影響大量的類，也會(huì)導(dǎo)致可讀性變差。這里有一些關(guān)于如何高效使用Optional的提示。

Optional 應(yīng)該只用于返回類型

…不能是參數(shù)和屬性. 閱讀這個(gè)博客 了解怎樣使用 Optional。 幸運(yùn)的是, IntelliJ IDEA 在打開 inspection功能的情況下會(huì)檢查你是否遵循了這些建議。

可選值應(yīng)該在使用的地方進(jìn)行處理. IntelliJ IDEA的建議可以防止你不恰當(dāng)?shù)氖褂肙ptional, 所以你應(yīng)該立即處理你發(fā)現(xiàn)的不恰當(dāng)使用Optional。(根據(jù)自己的理解翻譯)

你不應(yīng)該簡(jiǎn)單的調(diào)用get()

Optinal的目的是為了表示此值有可能為空，且讓你有能力來(lái)應(yīng)付這種情況。因此，在使用值之前進(jìn)行檢查是非常重要的。在某些情況下簡(jiǎn)單的調(diào)用get()而沒(méi)有先使用isPresent()進(jìn)行檢查是一樣會(huì)導(dǎo)致空指針問(wèn)題。幸運(yùn)的是，IntelliJ IDEA 任然會(huì)檢查出這個(gè)問(wèn)題并警告你。

有可能是一個(gè)更優(yōu)雅的方式

isPresent() 與 get()結(jié)合使用的技巧…

…但還有更優(yōu)雅的解決方案。你可以使用 orElse方法來(lái)使得當(dāng)它為null時(shí)給出一個(gè)代替的值。

…或者使用orElseGet方法來(lái)處理上述相同情況。這個(gè)例子和上面的看起來(lái)好像一樣，但本例是可以調(diào)用 supplier 接口的實(shí)現(xiàn),，因此如果它是一個(gè)高開銷的方法，可以使用 lambda 表達(dá)式來(lái)獲得更好的性能。

使用Lambda表達(dá)式

Lambda 表達(dá)式是 Java 8 的賣點(diǎn)之一.。即使你還沒(méi)有使用過(guò)Java 8， 到目前你也可能有一些基本的了解。但在Java編程中還是一種新的方式，它也不是明顯的”最佳實(shí)踐” 。 這里有一些我遵循的指南。

保持簡(jiǎn)短

函數(shù)式程序員更愿意使用較長(zhǎng)的lambda 表達(dá)式，但我們這些僅僅使用Java很多年的程序員來(lái)說(shuō)更容易保持lambda 表達(dá)式的短小。你甚至更喜歡把它們限制在一行，更容易把較長(zhǎng)的表達(dá)式重構(gòu)到一個(gè)方法中。

把它們變成一個(gè)方法引用，方法引用看起來(lái)有一點(diǎn)陌生，但卻值得這樣做，因?yàn)樵谀承┣闆r有助于提高可讀性，后面我再談可讀性。

明確的

(作者應(yīng)該想要表達(dá)的是: 參數(shù)命名規(guī)范，要有意義；有更好的翻譯請(qǐng)修正)

lambda 表達(dá)式中類型信息已經(jīng)丟失了，因此你會(huì)發(fā)現(xiàn)包含類型信息的參數(shù)會(huì)更有用。

如你所見(jiàn)，這樣會(huì)比較麻煩。因此我更喜歡給參數(shù)一個(gè)更有意義的命名。當(dāng)然，你做與否，IntelliJ IDEA 都會(huì)讓你看到參數(shù)的類型信息。

即使是在函數(shù)式接口的lambda 表達(dá)式中:

針對(duì)Lambda 表達(dá)式進(jìn)行設(shè)計(jì)

我認(rèn)為lambda表達(dá)式有點(diǎn)像泛型– 泛型,我們經(jīng)常使用它們 (例如, 給 List<>添加類型信息 )，但不常見(jiàn)的是我們把一個(gè)方法或類泛型化 (如: Person)。同樣的, 它就像我們使用通過(guò)lambdas包裝的 Streams API，但對(duì)我們來(lái)說(shuō)更罕見(jiàn)的是創(chuàng)建一個(gè)需要 lambda 表達(dá)式參數(shù)的方法。

如果你發(fā)現(xiàn)自己正處在這種情況的話，那么這里有一些不錯(cuò)的技巧。

IntelliJ IDEA 可以幫助你引入一個(gè)函數(shù)化的參數(shù)

這里讓你可以使用Lambda 表達(dá)式而非對(duì)象來(lái) 創(chuàng)建一個(gè)參數(shù) 。這個(gè)功能的好處在于其建議使用一個(gè)已有的 函數(shù)接口 來(lái)匹配這個(gè)規(guī)范。

這個(gè)將引導(dǎo)我們

使用已有的函數(shù)接口

當(dāng)開發(fā)者越來(lái)越熟悉Java 8 代碼時(shí)，我們會(huì)知道使用例如 Supplier 和 Consumer 這樣的接口會(huì)發(fā)生什么，但是單獨(dú)再創(chuàng)建一個(gè) ErrorMessageCreator 會(huì)讓我們很詫異并且很浪費(fèi)時(shí)間。你可以翻閱 function package 來(lái)查看系統(tǒng)本身已經(jīng)給我們準(zhǔn)備了什么。

為函數(shù)接口添加@FunctionalInterface 注解

如果你真的需要?jiǎng)?chuàng)建自己的函數(shù)接口，那么就需要用這個(gè)@FunctionalInterface 注解。這個(gè)注解似乎沒(méi)多大用處，但是 IntelliJ IDEA 會(huì)在接口不滿足這個(gè)注解要求的情況下予以提示。例如你沒(méi)有指定要繼承的方法：

指定太多的方法：

在類中使用注解而不是在接口：

Lambda 表達(dá)式可用于任意只包含單個(gè)抽象方法的接口中，但是不能用于滿足該要求的抽象類。看似不符合邏輯，但實(shí)際要求必須如此。

Streams

Stream API 是Java 8的另一大賣點(diǎn), 我認(rèn)為到現(xiàn)在為止，我們?nèi)匀徊恢肋@會(huì)對(duì)我們的編碼方式有多大改變．但我發(fā)現(xiàn)這是一個(gè)好壞參半的功能。

流式風(fēng)格

就我個(gè)人而言，更喜歡使用流式風(fēng)格．當(dāng)然你不必也這么做, 但我發(fā)現(xiàn)它幫助了我：

·一眼就能看出有哪些操作，它的執(zhí)行順序是什么

·更方便調(diào)試（雖然IntelliJ IDEA提供了在包含lambda表達(dá)式的行上設(shè)置斷點(diǎn)的能力，為了更方便調(diào)試，把它拆分到不同的行上）

·在測(cè)試的時(shí)候允許取消一個(gè)操作

·在調(diào)試或測(cè)試是，可以很方便的插入peek()

在我看來(lái)這樣寫很簡(jiǎn)潔。但是使用這種方法并沒(méi)有給我們節(jié)省多少代碼行。

你可能需要調(diào)整代碼格式化設(shè)置讓代碼看起來(lái)更加清晰。

使用方法引用

是的，你需要一點(diǎn)時(shí)間來(lái)適應(yīng)這個(gè)奇怪的語(yǔ)法。但如果使用恰當(dāng)，真的可以提升代碼的可讀性，看看下面代碼：

以及使用Objects 類的輔助方法：

后面一段代碼更加的明確可讀。IntelliJ IDEA 通常會(huì)知道怎么將一個(gè) Lambda 表達(dá)式進(jìn)行折疊。

當(dāng)對(duì)集合進(jìn)行元素迭代時(shí)，盡可能的使用Streams API

…或者用新的集合方法，例如 forEach. IntelliJ IDEA 會(huì)建議你這么做：

一般來(lái)說(shuō)使用Streams API 比起循環(huán)和 if 語(yǔ)句組合來(lái)得更加直觀，例如：

IntelliJ IDEA 會(huì)建議這樣的寫法進(jìn)行重構(gòu)：

我做過(guò)的性能測(cè)試顯示這種重構(gòu)帶來(lái)的結(jié)果比較奇怪，難以預(yù)測(cè)，有時(shí)候好，有時(shí)候壞，有時(shí)候沒(méi)區(qū)別。一如既往的，如果你的應(yīng)用對(duì)性能問(wèn)題非常在意，請(qǐng)認(rèn)真的進(jìn)行衡量。

遍歷數(shù)組時(shí)請(qǐng)用for 循環(huán)

然后，使用Java 8 并不意味著你一定要使用流 API 以及集合的新方法。IntelliJ IDEA 會(huì)建議一些做法改用流的方式重構(gòu)，但你不一定非得接受 (記住 inspections can be suppressed 或者 turned off).

特別是對(duì)一個(gè)原始類型的小數(shù)組時(shí)，使用for 循環(huán)的性能是最好的，而且代碼更具可讀性（至少對(duì) Streams API 的新手來(lái)說(shuō)是這樣）：

任何的技巧和提示都不是一成不變的，你應(yīng)該自己決定哪里需要使用Streams API ，而哪里還用循環(huán)操作。