1. 語言的分類

1.1. 靜態類型

1.1.1. 要求我們事先指定變數和函數的類型

1.2. 動態類型

1.2.1. 允許推遲指定類型

1.3. 強類型

1.3.1. 變數“知道”自己的類型

1.3.1.1. 允許反射和對實例作類型測試，且一直保有自身的類型信息

1.4. 弱類型

1.4.1. 語言相對不瞭解變數所指向的內容

2. 多範式

2.1. 面向對象

2.2. 元編程

2.2.1. 可用於在語言及其核心庫上添加額外的特性

2.3. 函數式

2.3.1. 函數式編程不喜歡把結構耦合在一起，它依靠零件之間的複合來組織抽象，以達到減少不確定因素的目的

2.3.2. 通過複合（composition）而不是耦合（coupling）來達到代碼重用的目的

2.4. 命令式

3. 多範式語言的後顧之憂

3.1. 要求開發者更註重紀律，才能駕馭好大型的項目

3.1.1. 依靠工程紀律來保證所有的開發者都朝著同一個方向努力，是解決協調問題的一種途徑

3.2. 單元測試為開發者精確地理解經元編程實現的複雜擴展提供了方便

3.3. 消費者驅動的契約（consumer-driven contract）

3.3.1. 由一項集成工作的實施方與各組件供應方共同商定的一組測試

4. 正交（orthogonality）

4.1. 數學上把兩個互相垂直的向量稱作正交的，也就是說這兩個量不相關

4.2. 在電腦科學里，兩個組件如果互相沒有任何影響（或副作用），就可以稱作是正交的

5. Groovy語言

5.1. 函數式編程和元編程是正交的

5.2. 使用元編程並不妨礙我們使用函數式編程的語言構造

5.2.1. 可以獲得更充分地實踐函數式的代碼風格

5.2.2. 可以用來增強第三方的函數式庫

5.2.2.1. 擁有了無縫添加新方法的能力

5.3. 利用元編程在數據類型之間建立映射

5.3.1. 開發者們一般只會考慮使用元編程來編寫自己的代碼，很少會想到用它來改造別人的代碼

6. 複合型（composable）抽象

6.1. Unix shell

6.1.1. 在shell命令行里，各種互相獨立、五花八門的行為可以串聯在一起創造出新的事物

6.2. Rake構建語言，可以用在各種公私項目上（幾乎不受項目本身技術選型的限制）

6.3. Gradle

6.3.1. Groovy語言的一種內部DSL，複合能力好於插件式設計的Maven

6.4. 不約而同地選擇了DSL的形式

6.5. 傾向於使用一些細粒度的部件來組成整體，且這些部件都已準備好以特定方式相連接

6.6. 較少隱性的行為，較容易上手，但傾向於提供細粒度的構造單元，需經過一定過程才能發揮真正的實力

6.6.1. 設計得當的複合型系統應當在封裝的模塊內提供窄範圍的、局部的上下文

7. 上下文型（contextual）抽象

7.1. Maven是典型的上下文型工具

7.2. 基於插件的架構可以作為上下文型抽象的代表

7.2.1. 提供了更多扶持性的“腳手架”設施，更完善的預設行為，以及“腳手架”上承載的上下文智能

7.3. Dietzler的Access定律

7.3.1. 所有Access項目最後都會失敗，原因是，在用戶想要的功能里，有80%實現起來既迅速又簡單，還有10%能實現但較困難，而最後的10%是辦不到的，因為不可能足夠深地突破內建抽象去訪問底層。可是，用戶總想100%地滿足需求。

7.3.1.1. 4GL語言最終丟掉了市場

8. 在函數式編程中傳統設計模式的三種歸宿

8.1. 模式已被吸收成為語言的一部分

8.2. 模式中描述的解決辦法在函數式範式下依然成立，但實現細節有所變化

8.3. 由於在新的語言或範式下獲得了原本沒有的能力，產生了新的解決方案

8.3.1. 很多問題都可以用元編程乾凈利落地解決，但Java沒有元編程能力可用

8.4. 設計模式的存在意義就是彌補語言功能上的弱點

9. 函數級別的重用

9.1. 複合（composition）

9.1.1. 通過參數來傳遞作為第一等語言成分的函數

9.2. 函數式語言的重用發生於較粗的粒度級別上，著眼於提取一些共通的運作機制，並參數化地調整其行為

9.2.1. 定義各類型“物件”之間“態射”（morphism）關係的數學分支——範疇論為基礎，希望從代碼中抽取另一種粗粒度的脈絡而加以重用

9.2.2. 不追求復現結構之間經典的（耦合）關係

9.2.3. 建立在列表的概念，以及可以連同執行上下文一起傳遞的代碼塊的概念之上

9.3. 以模式為載體的重用是細粒度的：一種解答方案（如Flyweight模式）與另一種解答方案（如Memento模式）之間，是井水不犯河水的“正交”關係

9.3.1. 模式和問題之間這種狹窄的對應關係又限制了它的適用面

10. Command模式

10.1. 當語言擁有了閉包特性，就不需要了

11. Factory模式

11.1. 柯里化相當於產出函數的工廠

11.2. 柯里化可以把通用的函數改造成專用的函數

12. Strategy模式

12.1. 定義一個演算法族，並將每一種演算法都在相同的介面下封裝起來，令同一族的演算法能夠互換使用

12.2. 好處是演算法的變化不影響使用方，也不受使用方的影響

13. Singleton模式

13.1. 模式被運行時吸收掉的典型案例

14. Template Method模式

14.1. 一個方法裡面定義好演算法的骨架，但留下一部分未實現的步驟，強迫子類按照規定好的演算法結構來補全缺失的步驟定義

14.2. 抽象方法的定義相當於一種特殊形式的文檔，提醒子類將指定的方法納入考慮

15. 被語言或運行時吸收掉的模式

16. Flyweight模式

16.1. 種在大量的細粒度對象引用之間共用數據的優化技巧。我們維護一個對象池，然後引用池中的對象來構成需要的視圖

16.2. 非常簡單的函數式實現

16.3. 記憶

16.4. 模式保留了原來的語義，但實現發生了變化