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. 模式保留了原來的語意，但實作發生了變化
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/542372.html
標籤：設計模式