1. 設計模式

1.1. 對設計經驗的歸納總結

1.2. 一種可重用的藍圖

1.3. Java 5引入了for-each迴圈

1.3.1. 替代了很多顯式使用迭代器的情形

1.4. Java 7推出的菱形操作符（<>）

1.4.1. 幫助大家在創建實例時無須顯式使用泛型

1.4.2. 推動了Java程式員們採用類型介面（type interface）進行程式設計

1.5. 單例模式

1.5.1. 一般用於限制類的實例化，僅生成一份對象

1.6. 訪問者模式

1.6.1. 常用於分離程式的演算法和它的操作對象

2. 策略模式

2.1. 解決一類演算法的通用解決方案，你可以在運行時選擇使用哪種方案

2.2. 一個代表某個演算法的介面（Strategy介面）

2.3. 一個或多個該介面的具體實現，它們代表了演算法的多種實現

2.4. 一個或多個使用策略對象的客戶

2.5. Lambda表達式避免了採用策略設計模式時僵化的模板代碼

3. 模板方法模式

3.1. 如果需要採用某個演算法的框架，同時又希望有一定的靈活度，能對它的某些部分進行改進

3.2. “希望使用這個演算法，但是需要對其中的某些行進行改進，才能達到希望的效果”時是非常有用的

3.3. 通過傳遞Lambda表達式，直接插入不同的行為，不再需要繼承

3.4. Lamba表達式能幫助解決設計模式與生俱來的設計僵化問題

4. 觀察者模式

4.1. 消除僵化代碼

4.1.1. 直接傳遞Lambda表達式表示需要執行的行為即可

4.2. 某些事件發生時（比如狀態轉變），如果一個對象（通常稱之為主題）需要自動地通知其他多個對象（稱為觀察者）

5. 責任鏈模式

5.1. 通過定義一個代表處理對象的抽象類來實現的，在抽象類中會定義一個欄位來記錄後續對象

5.2. UnaryOperator的一個實例

5.2.1. 為了鏈接這些函數，需要使用andThen方法對其進行構造

6. 工廠模式

6.1. 無須向客戶暴露實例化的邏輯就能完成對象的創建

6.2. 特殊的函數介面TriFunction

          public interface TriFunction<T, U, V, R>{
              R apply(T t, U u, V v);
          }
          Map<String, TriFunction<Integer, Integer, String, Product>> map
              = new HashMap<>();

7. 改善程式代碼的可讀性

7.1. 代碼的可讀性

7.1.1. 別人理解這段代碼的難易程度

7.1.2. 確保你的代碼能非常容易地被包括自己在內的所有人理解和維護

7.2. 重構代碼，用Lambda表達式取代匿名類

7.3. 用方法引用重構Lambda表達式

7.4. 用Stream API重構命令式的數據處理

8. 從匿名類到Lambda表達式的轉換

8.1. “更簡潔”來描述Lambda表達式是因為相較於匿名類

8.2. 匿名類和Lambda表達式中的this和super的含義是不同的

8.2.1. 在匿名類中，this代表的是類自身

8.2.2. 在Lambda中，它代表的是包含類

8.3. 匿名類可以屏蔽包含類的變數

8.4. Lambda表達式不能（會導致編譯錯誤）

8.5. 涉及重載的上下文里，將匿名類轉換為Lambda表達式可能導致最終的代碼更加晦澀

8.5.1. 匿名類的類型是在初始化時確定的

8.5.2. Lambda的類型取決於它的上下文

8.5.3. Task嘗試使用顯式的類型轉換來解決這種模棱兩可的情況

8.5.4. NetBeans、Eclipse和IntelliJ都支持這種重構，能自動地幫你檢查，避免發生這些問題

9. 從Lambda表達式到方法引用的轉換

9.1. Lambda表達式非常適用於需要傳遞代碼片段的場景

9.2. 儘量將複雜的Lambda表達式抽象到普通方法中

9.3. 為了改善代碼的可讀性，請儘量使用方法引用

9.3.1. 利用這種方法能寫出非常簡潔的代碼

9.4. 儘量考慮使用靜態輔助方法

9.4.1. 比如comparing和maxBy

9.4.2. 這些方法設計之初就考慮了會結合方法引用一起使用

10. 從命令式的數據處理切換到Stream

10.1. Stream API能更清晰地表達數據處理管道的意圖

10.2. 建議將所有使用迭代器這種數據處理模式處理集合的代碼都轉換成Stream API的方式

10.3. 通過短路和延遲載入以及電腦的多核架構，可以對Stream進行優化

10.3.1. LambdaFicator

11. 增加代碼的靈活性

11.1. 採用函數介面

11.1.1. 沒有函數介面，就無法使用Lambda表達式

11.2. 有條件的延遲執行

11.2.1. 控制語句被混雜在業務邏輯代碼之中

11.2.2. 頻繁地從客戶端代碼去查詢一個對象的狀態，只是為了傳遞參數、調用該對象的一個方法，那麼可以考慮實現一個新的方法，以Lambda或者方法引用作為參數，新方法在檢查完該對象的狀態之後才調用原來的方法

11.2.3. 代碼會因此而變得更易讀（結構更清晰），封裝性更好（對象的狀態也不會暴露給客戶端代碼了）

11.3. 環繞執行

11.3.1. 擁有同樣的準備和清理階段

12. 測試Lambda表達式

12.1. 測試可見Lambda函數的行為

12.2. 測試使用Lambda的方法的行為

12.2.1. Lambda的初衷是將一部分邏輯封裝起來給另一個方法使用

12.2.2. 不應該將Lambda表達式聲明為public，它們僅是具體的實現細節

12.3. 將複雜的Lambda表達式分為不同的方法

12.3.1. 將Lambda表達式轉換為方法引用

12.3.2. 需要聲明一個新的常規方法

12.3.3. 用常規的方式對新的方法進行測試

12.4. 高階函數的測試

12.4.1. 如果一個方法接受Lambda表達式作為參數，那麼你可以採用的一個方案是使用不同的Lambda表達式對它進行測試

13. 調試

13.1. 查看棧跟蹤

13.1.1. 由於Lambda表達式沒有名字，因此它的棧跟蹤可能很難分析

13.2. 使用日誌調試

13.2.1. 流操作方法peek

13.2.2. peek的設計初衷就是在流的每個元素恢復運行之前，插入執行一個動作