1. 面向物件編程
1.1. （Object-Oriented Programming，OOP）
1.2. 基于物件的概念的一種編程范式
1.3. 物件可以包含資料和代碼
1.4. 資料是物件的狀態
1.5. 代碼是一個或多個方法
1.5.1. 訊息是方法，包括名稱、實參和回傳型別
1.6. 通過使用其他物件的方法，物件之間可以“對話”或者發送訊息
1.7. 關鍵特征
1.7.1. 封裝
1.7.1.1. 允許隱藏資料和方法
1.7.2. 繼承
1.7.2.1. 用額外的資料和代碼擴展一個型別
2. 介面
2.1. 契約
2.2. 描述了實作該介面的任何物件都理解的一組訊息
2.3. 介面沒有任何狀態
2.4. 相當于書面協議
2.4.1. 規定了實作者將提供什么
2.5. ConsoleLogger滿足了ILogger的契約
2.5.1. 并不是一個ILogger
2.5.2. Java和C#規定一個類只能從另外一個類繼承，但它們允許類實作許多介面，這就是原因所在
2.6. 合并介面的能力允許我們從較小的、可重用的介面創建合并后的介面
2.7. 介面最終讓消費者受益，而不是讓實作介面的類獲益
2.8. “針對介面編程”是著名的OOP原則
3. 抽象類
3.1. 可以包含非抽象的方法或狀態
3.2. 和具體類的唯一區別在于不能直接創建抽象類的實體
3.3. ConsoleLogger和AbstractLogger之間的關系是所謂的“是”關系
3.3.1. ConsoleLogger繼承了AbstractLogger
3.3.2. ConsoleLogger也是一個AbstractLogger
4. 繼承
4.1. 子類是父類的子型別
4.1.1. 在期望使用父類的任何地方，都可以使用子類的實體
4.2. 繼承會在子型別與父型別之間建立“是一個”關系
4.3. 不要創建出非常深的類層次
4.3.1. 一個物件的多個狀態和方法可能來自層次結構中的不同級別，導致代碼更難理解
4.4. 讓子類是具體類，讓層次結構上方的父類是抽象類，這是一個好主意
4.5. 盡可能多地使用final或sealed等關鍵字實作某個子類顯式標記為不可繼承
4.6. 使用繼承來代表層次，或者通過使用抽象或重寫方法來實作引數化行為
5. 組合
5.1. 比繼承更好的方法
5.2. 只要可能，就優先選擇組合而不是繼承是著名的OOP原則
5.3. “有一個”經驗準則
5.3.1. 不是從一個型別繼承行為，而是定義一個該型別的屬性
5.3.2. 對于判斷什么時候應該使用組合而言是一個很好的測驗
5.4. 除非兩個型別之間存在清晰的“是一個”關系，否則組合是可以默認使用的好方法
5.5. 組合在容器型別和被包含型別之間建立了一種“有一個”關系
5.6. 優點：組件屬性的所有狀態被封裝在這些組件中，所以型別變得整潔多了
5.7. 不是把幾個組件合并到一起，而是封裝一個組件，并提供它需要的“膠水”代碼，使其能夠作為另外一種型別使用
6. 值型別和 參考型別
6.1. 在C#中結構是值型別
6.2. 除了原生提供的基本數值型別，Java不支持值型別
6.2.1. 幾乎所有型別都是參考型別
6.3. 在C++中
6.3.1. 所有型別都是按值傳遞的，除非我們顯式地將一個值宣告為指針（*）或者參考（&）
6.3.2. 結構只是意味著其成員默認是公有的
6.3.3. 類的成員默認是私有的
6.4. 一些函式式語言
6.4.1. 使用不可變資料
6.4.2. 此時不存在值和參考之間的區別
7. 配接器模式
7.1. 能夠讓兩個類變得兼容，而且不需要我們修改其中任何一個類
7.2. 對于處理我們無法修改的代碼極為有用
7.2.1. 例如不在我們控制內的外部庫的代碼
7.3. 不修改型別，而是使用封裝和組合讓型別適配不同介面的一個例子
8. 混入
8.1. 有爭議的概念
8.2. 混入行為通常是使用多重繼承實作的
8.2.1. 擴展閱讀了解”菱形繼承”問題
8.3. “是一個”經驗準則發生了沖突
8.4. 在一個型別與其混入型別之間建立了“包含”關系
8.5. 許多語言為了保持簡單，選擇根本不支持混入
8.6. 大部分支持混入的語言中，混入另外一個型別與繼承無法沒有區別
8.7. 混入對于減少樣板代碼很有用
8.8. 混入最適合實作橫切關注點（cross-cutting concern）
8.8.1. 參考計數
8.8.2. 快取
8.8.3. 持久化
8.8.4. 日志
8.8.5. 安全
8.9. 編譯時方案
8.9.1. 在C++中，我們可以使用多重繼承來把一個型別宣告為其他兩個型別的組合
8.10. 運行時方案
8.10.1. 在TypeScript中的交叉型別
8.10.1.1. 使用extend()函式
8.11. 與繼承不同，使用混入時，我們為不同的行為方面定義不同的型別，然后把它們合并起來，放到一個完整的型別中
8.11.1. 有一些屬性和方法是特定物件所獨有的
8.11.2. 另一些屬性和方法是多個型別所共有的
8.12. 使用混合來為型別添加行為
9. 純粹面向物件代碼的替代方案
9.1. 它們不會替代OOP，但在一些情況中是更好的選擇
9.2. 和型別
9.2.1. 以相同的方式傳遞不同型別的物件，或者把它們放到一個公共的集合中，使用和型別，此時不需要在型別之間建立任何關系，就可以獲得相同的行為
9.3. 函式式編程
9.3.1. 避免了維護狀態：函式可以接受一組實參，執行一些計算，然后回傳結果，并不需要改變任何狀態
9.3.2. 如果IExpression更加復雜，宣告了多個方法，那么面向物件方法的效果可能更好
9.4. 泛型編程
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/542054.html
標籤：其他
下一篇：CAP特性與Base理論