1. SOLID原則
1.1. 開發良好面向物件程式的準則
1.2. Liskov substitution里氏替換
1.3. Interface segregation介面隔離
1.4. Single responsibility單一功能原則
1.4.1. 程式中的類或方法只能有一個改變的理由
1.4.2. 一個類不僅要功能單一，而且還需將功能封裝好
1.5. Open/closed開閉原則
1.5.1. 軟體應該對擴展開放，對修改閉合
1.5.1.1. 讓軟體易于修改
1.5.2. 高階函式在用多型來實作開閉原則
1.5.3. 使用不可變物件實作開閉原則
1.6. Dependency inversion依賴反轉原則
1.6.1. 抽象不應依賴細節，細節應該依賴抽象
1.6.1.1. 待依賴的抽象不必是介面
1.6.2. 讓程式員脫離底層粘合代碼，撰寫上層業務邏輯代碼
1.6.3. 高階函式提供了反轉控制
1.6.4. 模塊化和重用方式是雙向的
1.6.4.1. 可以替換不同的細節重用上層代碼
1.6.4.2. 可以替換不同的業務邏輯重用細節的實作
2. 不可變性
2.1. 觀測不可變性
2.1.1. 在其他物件看來，該類是不可變的
2.1.2. java.lang.String
2.1.2.1. 第一次呼叫hashCode方法時快取了生成的散列值
2.1.3. 觀測不可變性不意味著實作不可變性
2.2. 實作不可變性
2.2.1. 物件本身不可變
2.2.2. 實作不可變性意味著觀測不可變性
3. 設計模式
3.1. 有些模式會變得過時
3.2. Lambda能讓很多現有設計模式更簡單、可讀性更強
3.2.1. 將大量代碼塞進一個方法會讓可讀性變差是決定如何使用Lambda運算式的黃金法則
4. 單例模式
4.1. 應該避免使用的模式
4.2. 敏捷開發使其成了一個反模式
5. 命令者模式
5.1. 命令者是一個物件，它封裝了呼叫另一個方法的所有細節
5.2. 使用該物件，可以撰寫出根據運行期條件，順序呼叫方法的一般化代碼
5.3. 函式介面Runnable
5.4. 宏只是使用命令者模式的一個例子，它被大量用在實作組件化的圖形界面系統、撤銷功能、執行緒池、事務和向導中
5.5. 使用Lambda運算式或是方法參考，能讓代碼更簡潔，去除了大量樣板代碼，讓代碼意圖更加明顯
6. 策略模式
6.1. 能在運行時改變軟體的演算法行為
6.2. 定義一個通用的問題，使用不同的演算法來實作，然后將這些演算法都封裝在一個統一介面的背后
6.3. 使用Lambda運算式或者方法參考可以去掉樣板代碼
7. 觀察者模式
7.1. 可被Lambda運算式簡化和改進的行為模式
7.2. 被觀察者持有一個觀察者串列，當被觀察者的狀態發生改變，會通知觀察者，
7.3. 觀察者模式被大量應用于基于MVC的GUI工具中，以此讓模型狀態發生變化時，自動重繪視圖模塊，達到二者之間的解耦
8. 模板方法模式
8.1. 整體演算法的設計是一個抽象類，它有一系列抽象方法，代表演算法中可被定制的步驟，同時這個類中包含了一些通用代碼
8.2. 演算法的每一個變種由具體的類實作，它們重寫了抽象方法，提供了相應的實作
8.3. 將一組方法呼叫按一定順序組織起來
8.4. 如果用函式介面表示函式，用Lambda運算式或者方法參考實作這些介面，相比使用繼承構建演算法，就會得到極大的靈活性
8.4.1. 使用函式介面實作方法并沒有排除繼承的方式
9. 領域專用語言（DSL）
9.1. 針對軟體系統中某特定部分的編程語言
9.1.1. 比較小巧
9.1.2. 表達能力也不如通用語言強
9.1.3. 不求面面俱到，但求有所專長
9.2. Domain-Specific Languages
9.2.1. Martin Fowler和Rebecca Parsons合著
9.2.2. Addison-Wesley出版社出版
9.3. 外部DSL
9.3.1. 脫離程式原始碼撰寫，然后單獨決議和實作
9.3.2. 例如
9.3.2.1. 級聯樣式表（CSS）
9.3.2.2. 正則運算式
9.4. 內部DSL
9.4.1. 嵌入撰寫它們的編程語言中
9.4.2. 普通的類別庫，提供API方便使用
9.4.3. 例如
9.4.3.1. JMock
9.4.3.2. Mockito
9.4.3.3. JOOQ
9.4.3.4. Querydsl
10. 行為驅動開發（BDD）
10.1. 測驗驅動開發（TDD）的一個變種
10.2. 它的重點是描述程式的行為，而非一組需要通過的單元測驗
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/542762.html
標籤：其他