目前JDK8引進了Lambda專案,包括了Lambda語法、方法參考(Method reference)、Stream API、函數式風格API,以及平行處理等重大特性,如果你要轉進JDK8了,那麼,是不是過去可用的方式,都要改採Lambda的相關特性來實現呢?

面對一個問題會有多種風格的解法時,你是否一定要選擇Lambda呢?

依可讀性考量

從最簡單的角度來看待Lambda語法,就是將之當作匿名類別(Anoynmous class)的語法蜜糖,不用理會類別名稱,也不用管方法名稱,在型態推斷(Type inference)的輔助下,連參數型態與傳回型態都可以省略,撰寫程式時可以少打一些字,對減少程式碼數量是有幫助。

然而,減少程式碼數量不見得有助於可讀性,如果拿掉匿名類別語法上的名稱與型態資訊,反而使得你必須察看API文件才能理解程式碼(特別是在沒有IDE輔助下),那麼你就不應當使用Lambda語法,是否使用方法參考,也是視程式碼展現的可讀性而定。

JDK8中有許多搭配Lambda語法的高階API,這類API抽取了可重用的流程,在名稱上顯露出高階語義,自然地,當你使用它們時,要確認自己(或夥伴)瞭解名稱代表什麼,且不在意內部實作細節,否則的話,反而會在閱讀程式碼時失去了直覺而感到困惑。

舉例來說,Map的forEach語法在迭代鍵值很值得使用,因為相較於使用for迴圈來說,可讀性高且forEach名稱清楚易懂。相對地,如果若原本有段直覺的程式碼:

List<String> itemNames = new ArrayList<>();
for(Order order : orders) {
    for(LineItem lineItem : order.getLineItems()) {
        itemNames.add(lineItem.getName());
    }
}

不用任何說明,從程式碼中可以一眼看出來,執行目的是從每個訂單中收集品項名稱,你可以試著將之改成Lambda版本,兩個版本要撰寫的程式碼數量其實是差不多,思考一下,如果你(或夥伴)對於map、flatMap的語義清不清楚,而這些方法又隱藏了可重用的流程細節,對程式碼的閱讀是否會有幫助?

List<String> itemNames = orders.stream()
       .map(Order::getLineItems)
       .flatMap(lineItems -> lineItems.stream())
       .map(LineItem::getName)
       .collect(toList());

考量管線操作的實質作用

JDK8中搭配Lambda的API多半使用管線(Pipeline)操作,目前作用之一是呈現流暢風格,讓程式碼伴演著內部DSL的角色,除了可讀性的考量之外,可考量實質作用。

舉例來說,Stream API實現了惰性求值(Lazy evaluation),同樣是讀取檔案,Files現在有readAllLines與lines兩個方法可以使用,然而對於以下的情況:

for(String line : readAllLines(get(fileName))) {
    if(line.startsWith(prefix)) {
        matched = line; break;
    }
}

修改為以下的Lambda版本,若檔案內容較大時會比較有效率,因為lines方法不會一次讀入全部檔案,而filter方法也不會對全部的行做測試,第一行內容的讀取與測試發生在findFirst被呼叫之後,在最極端的狀況下,如果檔案中第一行就符合條件,後續的檔案讀取就不會進行:

try(Stream<String> lines = lines(get(fileName))) {
    Optional<String> matched = lines.filter(line -> line.startsWith(prefix))
                                    .findFirst();
}

管線操作中的每個方法呼叫,其實各自隱藏了不少細節,閱讀程式碼時多半沒那麼直覺,然而,如果面對複雜的問題,例如非同步處理的連續組合需求,那麼使用CompletableFuture這類API,來避免我先前專欄〈非同步操作的多種模式〉中談到的回呼地獄(Callback hell),相對來說,如此反而就比較直覺了。

如果你的程式改為Lambda風格,對於可讀性沒有幫助,也沒有管線化操作上的實質意義,像是簡單的陣列迭代,那麼就不必要特別使用Arrays.stream,將陣列包裏為Stream了。

平行處理前的重構手段

使用Lambda相關的API時你會發現,它們幾乎只接受一個Lambda,也就是一次只能指定一件事,當你打算將一個程式區塊轉為Lambda相關作法前,你會因此被迫先對該區塊進行重構,成為數個各自獨立且只產生一個結果的小區塊,而當上一個小區塊的結果會作為下一個小區塊的起始條件時,你就有機會進行管線操作,在《重構:改善既有程式的設計》中就談過,想解構程式中的邏輯泥塊,就是讓它們一次只做一件事。

JDK8提供高階語義的管線化API,目的之一,就是希望你思考處理的過程中,實際上是由哪些小任務組成。

在過去,你可能基於(自我想像的)效能增進考量,在迴圈中做了很多件事,因而讓程式變得複雜,打算重構或許也沒有具體可憑藉的手段,也許,試著從Lambda提供哪些高階API來思考會是個可行方向,畢竟為了套用API,被迫重構的成份居多,然而換取而來的效果,就是API會在可能的情況下實現惰性、平行處理能力。

就Lambda語法本身,以及JDK8的高階語義API,許多概念都可追溯至函數式程式設計,不過,這並不是鼓勵Java開發者撰寫純函數程式,而是要讓開發者在撰寫平行處理程式碼時能更為簡化,在最簡單的情況下,可以將stream方法換為parallelStream,就能得到平行處理的可能性。

然而,天下沒有白吃的午餐,在這之前,開發者要懂得讓程式碼一次做一件事,將複雜的程式區塊切割成許多小任務,另外,還要留意程式執行順序,並且避免在每個小任務執行時,對Stream來源資料進行干擾。

多一種工具、多一個思考角度

從其他語言來看Lambda的東西都不是新的,就算只從Java的領域來看Lambda的東西也不是新的,像是JDK8中許多API,在guava-libraries中都有對應的類似API,只不過,在缺少Lambda語法之下,多少影響了使用的意願。

guava-libraries在一篇〈FunctionalExplained〉也談到,除非使用這些API進行函數式風格設計時,對可讀性有所幫助,或者是取得了惰性處理上的一些益處,不然就算使用了guava-libraries,命令式仍應是JDK7與先前版本的風格選擇,為此,對於同一件事的解決,guava-libraries在不少API中,都提供了兩種風格的選擇。

實際上,這類考量在JDK8之後依然是可行的,解決問題不僅一種方式,就算是簡單的迭代,也有迴圈或forEach兩種風格可以選擇,在Lambda語法的直接支援下,選擇哪種工具解決問題都很方便,當手邊多了一種工具,實際上你是多了一個思考角度,拒絕使用,或一味認為用上最新的東西就是最好,都只是在放棄多一個思考角度的機會。

作者簡介


Advertisement

更多 iThome相關內容