1. 觀點

1.1. 抽象隱藏了繁雜的細節，只是有時候會連同重要的考慮因素一起隱藏掉

1.2. 理解掌握的抽象層次永遠要比日常使用的抽象層次更深一層

1.3. 交出控制權的觀點：放棄對繁瑣細節的掌控，關注問題域，而非關注問題域的實作

2. 函式式思維的好處

2.1. 將低層次細節（如垃圾收集）的控制權移交給運行時，從而消弭了一大批注定會發生的程式錯誤

2.2. 函式式語言的簡潔語法和靈活配合，才使遞回成為簡單可行的代碼重用選項之一

2.3. 運行時有能力在涉及效率的問題上替我們做決定

2.4. 從頻繁出現的場景中消滅掉煩人的實作細節

3. 閉包（closure）

3.1. 一種特殊的函式，在生成的時候，會把參考的變數全部圈到代碼塊的作用域里，封閉、包圍起來（故名閉包）

3.1.1. 閉包作為一種對行為的建模手段，讓我們把代碼和背景關系同時封裝在單一結構，也就是閉包本身里面，像傳統資料結構一樣可以傳遞到其他位置，然后在恰當的時間和地點完成執行

3.2. 閉包的每個實體都保有自己的一份變數取值，包括私有變數也是如此

3.2.1. 代碼塊實體從它被創建的一刻起，就持有其作用域內一切事物的封閉副本

3.3. 在缺乏閉包特性的舊版Java平臺上，Functional Java利用匿名內部類來模仿“真正的”閉包的某些行為，但語言的先天不足導致這種模仿是不徹底的

3.4. 當作一種異地執行的機制，用來傳遞待執行的變換代碼

3.5. 是推遲執行原則的絕佳樣板

3.6. 抓住背景關系，而非狀態

3.6.1. “讓運行時去管理狀態”

4. 柯里化（currying）和函式的部分施用（partial application）

4.1. 向一部分引數代入一個或多個默認值的辦法來實作的

4.1.1. 這部分引數被稱為“固定引數”

4.2. 柯里化

4.2.1. 從一個多引數函式變成一連串單引數函式的變換

4.2.2. 結果是回傳鏈條中的下一個函式

4.3. 部分施用

4.3.1. 通過提前代入一部分引數值，使一個多引數函式得以省略部分引數，從而轉化為一個引數數目較少的函式

4.3.2. 把引數的取值系結到用戶在操作中提供的具體值上，因而產生一個“元數”（引數的數目）較少的函式

4.4. Groovy

4.4.1. curry()函式實作柯里化

4.5. Clojure

4.5.1. (partial f a1 a2 …)函式

4.5.2. 沒有將柯里化實作成一種語言特性，相關的場景交由部分施用去處理

4.6. Scala

4.6.1. 柯里化

4.6.2. 部分施用函式

4.6.3. 偏函式

4.6.3.1. PartialFunction trait是為了密切配合語言中的模式匹配特性

4.6.3.2. trait并不生成部分施用函式，它的真正用途是描述只對定義域中一部分取值或型別有意義的函式

4.6.3.3. Case陳述句是偏函式的一種用法

4.6.3.4. 偏函式的引數被限定了取值范圍

4.6.3.5. 可以把偏函式用在任何型別上，包括Any

4.7. 大多數函式式語言都具備柯里化和部分施用這兩種特性，但實作上各有各的做法

4.8. 用途

4.8.1. 函式工廠

4.8.1.1. 工廠方法的場合，正適合柯里化（以及部分施用）表現它的才干

4.8.2. Template Method（模板方法）模式

4.8.2.1. 在固定的演算法框架內部安排一些抽象方法，為后續的具體實作保留一部分靈活性

4.8.3. 隱含引數

5. 遞回

5.1. 以一種自相似的方式來重復事物的程序

5.2. 對一個不斷變短的串列反復地做同一件事，把遞回用在這樣的場合，寫出來的代碼就容易理解

5.3. 遞回操作往往受制平臺而存在一些固有的技術限制，因此這種技法絕非萬靈藥

5.4. 但對于長度不大的串列來說，遞回操作是安全的

5.5. 語言在管理回傳值，它從遞回堆疊里收集每次方法呼叫的回傳結果，構造出最終的回傳值

5.6. 利用遞回，把狀態的管理責任推給運行時

6. 記憶（memoization）

6.1. 用更多的記憶體（我們一般不缺記憶體）去換取長期來說更高的效率

6.1.1. 快取可以提高性能，但快取有代價：它提高了代碼的非本質復雜性和維護負擔

6.1.2. 負責撰寫快取代碼的開發者不僅要顧及代碼的正確性，連它的執行環境也要考慮在內

6.1.3. 代碼中的狀態，開發者不僅要費心照應它，還要條分縷析它的一切明暗牽連

6.2. 記憶的內容應該是值不可變的

6.3. 保證所有被記憶的函式

6.3.1. 沒有副作用

6.3.2. 不依賴任何外部資訊

6.4. 只有純（pure）函式才可以適用快取技術

6.4.1. 純函式是沒有副作用的函式

6.4.1.1. 它不參考其他值可變的類欄位

6.4.1.2. 除回傳值之外不設定其他的變數

6.4.1.3. 其結果完全由輸入引數決定

6.4.2. 只有在函式對同樣一組引數總是回傳相同結果的前提下，我們才可以放心地使用快取起來的結果

6.5. 快取是很常見的一種需求，同時也是制造隱晦錯誤的源頭

6.6. 兩種情況

6.6.1. 類內部快取

6.6.1.1. 類中的快取就代表類有了狀態，所有與快取打交道的方法都不可以是靜態的，于是產生了更多的連鎖效應

6.6.2. 外部呼叫

6.7. 兩種實作方式

6.7.1. 手工進行狀態管理

6.7.2. 采用記憶機制

6.8. 在命令式的思路下，開發者是代碼的主人（以及一切責任的承擔者）

6.9. 我們寫出來的快取絕不可能比語言設計者產生的更高效，因為語言設計者可以無視他們給語言定的規矩：開發者無法觸碰的底層設施，不過是語言設計者手中的玩物，他們擁有的優化手段和空間是“凡人”無法企及的

6.9.1. 上帝視角

6.10. Groovy

6.10.1. 先將要記憶的函式定義成閉包，然后對該閉包執行memoize()方法來獲得一個新函式，以后我們呼叫這個新函式的時候，其結果就會被快取起來

6.10.2. memoizeAtMost(1000)

6.11. Clojure

6.11.1. (memoize )

6.12. Scala

6.12.1. 沒有直接提供記憶機制，但它為集合提供的getOrElseUpdate()方法已經替我們承擔了大部分的實作作業

6.13. Java 8

6.13.1. 沒有直接提供記憶特性，但只要借助它新增的lambda特性，就可以輕松地實作記憶功能

7. 緩求值（lazy evaluation）

7.1. 盡可能地推遲求解運算式

7.1.1. 昂貴的運算只有到了絕對必要的時候才執行

7.1.2. 可以建立無限大的集合，只要一直接到請求，就一直送出元素

7.1.3. 按緩求值的方式來使用映射、篩選等函式式概念，可以產生更高效的代碼

7.1.4. 減少占用的存盤空間，假如能夠用推導的方法得到后續的值，那就不必預先存盤完整的串列了——這是犧牲速度來換取存盤空間的做法

7.2. 非嚴格求值（non-strict）的（也叫緩求值，lazy）

7.2.1. 常用的非嚴格求值語言有Haskell

7.3. Totally Lazy框架（Java）

7.4. Groovy

7.4.1. 緩求值串列是函式式語言普遍具備的特性

7.4.1.1. LazyList

7.4.2. 暫緩初始化昂貴的資源，除非到了絕對必要的時候

7.4.3. 可以用來構建無限序列，也就是沒有上邊界的串列

7.4.4. 緩求值串列特別適用于資源的生產成本較高的情況

7.5. Clojure

7.5.1. 資料結構都是默認緩求值的

7.6. Scala

7.6.1. 沒有把一切都默認安排成緩求值的，而是在集合之上另外提供了一層緩求值的視圖

7.7. 緩求值的欄位初始化

7.7.1. Scala

7.7.1.1. val宣告前面加上“lazy”字樣

7.7.1.1.1. 令欄位從嚴格求值變成按需要求值

7.7.2. Groovy

7.7.2.1. 抽象語法樹（Abstract Syntax Tree，AST）

7.7.2.1.1. @Lazy標注

8. 元函式技法

8.1. 操縱的物件是函式本身，而非函式的結果

8.2. 柯里化

標籤：其他

上一篇：配接器模式

下一篇：配接器模式