
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的設計初衷就是在流的每個元素恢復運行之前,插入執行一個動作
轉載請註明出處,本文鏈接:https://www.uj5u.com/houduan/544104.html
標籤:其他
上一篇:01-進制之間的轉換
