此為過去的舊文，2014 年 4 月 13 日初次發表於 logdown。
即使沒有 Stream，Java Collection framework 的設計仍是相當不錯，只是有時候需要一些簡單的功能，例如：根據某些條件查找容器中的某個物件，總是要寫個 for 迴圈，程式不難但寫久了也覺得煩。在沒有類似 for in 的語法糖衣之前，index 的管理很惱人。若是巢狀迴圈，index 命名不好遇到問題 debug 起來更是頭痛，用過 Apache Commons Collections 後，Apache Commons Collections 幾乎是專案裡必備的套件。先來個簡單例子，假設想在放 Person 物件的 List 中找姓名含某個特定值時，傳統的寫法如下，會是寫一個 for 迴圈，然後逐一檢查每個person物件的姓和名。
那如果用 Apache Commons Collections 又會如何呢？請看下面的範例，基本上不需要寫 for 迴圈，只要在呼叫 find 時傳一個實作 Predicate 介面的物件即可，該物件只需要實作 evaluate 這個method，判斷是否滿足條件，滿足回傳 true，就這樣。什麼！程式碼行數變多，沒錯，確實變多，但 PersonNamePredicate 這物件是可以重複使用的，若觀察 CollectionUtils 這個 class 就會發現有 12 個 methods 利用 Predicate 物件對容器進行過濾、選擇、計數等操作，加上 Predicate 的實作要測試很容易，所以這樣寫很划算。
null』，迴圈的操過被忽略了，是否有感覺抽象程度被提高了呢？那如果要像 Apache Commons Collections 那樣，可以辦到嗎？可以！首先，像下例，寫個 StreamUtils 輔助類別，提供一個 find(Collection, Predicate) 函式，然後改寫 PersonNamePredicate，接著就可以只寫一行就搞定。當然，如果不打算讓 PersonNamePredicate 同時支援 Apache Commons Collections 及 Java Stream，只需實作 java.util.Predicate 介面的 test 函式就好。
不過繞了一大圈，為的是什麼？除了使用parallelStream()可能帶來平行處理的好處外，這個版本並沒有帶來太多的好處，主要是應用(find)太簡單了，用Stream有點殺雞用牛刀的感覺。
Java Stream API 的概念類似 Unix Pipeline 或 pipes and filters design pattern，透過串接多個簡單的 operation 完成有意義的工作，由於 operation 通常都很簡單，所以使用 Lambda expression 多數時候可以帶來簡潔和提升可讀性的好處。
Figure 1 - Stream Pipeline
如 Figure 1 所示，Java Stream 能串多個 intermediate operations，但最後只能串一個 terminal operation 來組成 pipeline。用 intermediate operation 轉換 stream 內容，例如：過濾 (filter(Predicate))、替換 (map(Function))、排序 (sorted(Comparator)) 等，然後用 terminal operation 對 stream 內的資料計算最終結果或產生 side effect，例如：收集 (collect(Collector))、逐一改變 (forEach(Consumer)) 或歸納 (Reduce(BinaryOperator)) 等。
Figure 2 - Stream Pipeline Example
例如，可以用 Figure 2 的 pipeline 來計算資料中資產超過 10 億元的富豪，其資產的總合，首先 filter(Predicate) 過濾出資產超過 10 億元的資料，接著用 map(Function) 取出資產的部分，最後用 reduce(BinaryOperation) 做歸納。事實上，類似的運算實在太常用了，因此 Java Stream API 中有個 Collectors 類別提供常用的 terminal operation，例如 summarizingDouble(ToDoubleFunction) 就結合了 map(Function) 和預設的 reduce(BinaryOperation) 實作，簡化 pipeline 的組成。
覺得例子有點抽象？那再來一個更具體的例子吧。假設 Exam 代表一種測驗，每個人可以參加多次測驗，因此 Person 有一個 List 存放受測者參加過的所有測驗。假如想要取得曾經得超過 700 分的所有受測者排名，為了不寫重複的程式碼，如下面的範例程式，先將取得受測者曾經參加過的測驗最高分寫成 Person 的 getHighestScore() 函式 (仍用Stream API)。
接著就可以寫一個 showRank(List<Person>, double) 的函式，第一個參數是所有受測者，第二個參數是排行榜顯示的門檻。程式首先呼叫 stream() 取得 Stream 物件，接著對 Stream 呼叫 filter(Predicate) 函式，這裡用 Lambda Expression 就覺得很自然，也提高可讀性。
過濾掉低於門檻值的受測者後，呼叫 sorted(Comparator) 進行排序，然後 map(Function) 將受測者的全名與分數組成字串 (例如："Spirit Tu: 840.0") 當成結果，這邊要小心的是 map(Function) 所回傳的 Stream 物件，裡面裝的已經不是 Person 物件了，而是字串，所以 forEach(Consumer) 的 Lambda Expression 中，e 代表的是字串，直接就可以顯示在 console 上。
最後，呼叫 showRank(persons, 700) 就可以看到曾經得超過 700 分的受測者排行榜了。整個流程可以畫成如 Figure 3的 pipeline。
Figure 3 - The pipeline for showRank
老實說，看到 Java Sream API 讓我感到相當親切，這應該跟我研究所多年的研究題目是 visual dataflow language 有關，在 VisualTPL 中，迴圈的概念被內化了，重點在於做什麼運算 (what)，而不是如何跑迴圈 (how)，同樣地，Java Stream API 也是把迴圈給內化了，每個 operation 的重點是要做什麼，大大提高了程式的抽象化程度和可讀性。不過 Java Stream API 的特色還不只這些，剩下的下一篇再討論。
