《設計模式》1、面向對象的六大原則

本系列文章爲學習 《Android 源碼 設計模式 解析與實戰》筆記。主要記錄知識點的基本介紹以及我的見解。 該書結合 Android 源碼 爲讀者介紹 設計模式。爲設計模式入門書籍，主要介紹設計模式的定義、簡單實用、經典案例、以及在Android 源碼中的應用 該書第一部分爲你們介紹了「面向對象的六大原則」

1. 單一責任原則 SRP（Single Responsibility Principle）

定義：就一個類而言，應該僅有一個引發它變化的緣由。 簡單的說就是：一個類中應該是一組相關性很高的函數、數據的封裝。若是一個類承擔過多的責任，就至關於把這些責任耦合在一塊兒了，當一個責任變化時可能會削弱或者抑制這個類完成它完成其餘責任的能力。好比MVC 模式中的Activity 及承擔了用戶交互，又承擔了Controller 邏輯處理。致使Activity 代碼臃腫，引發變化的緣由變多。

2. 開閉原則 OCP（Open Close Principle）

定義：軟件中的對象（類、模塊、函數等）應該對於擴展是開發的，可是對於修改是封閉的。 在軟件的生命週期內容，變化升級和維護等須要修改軟件時，可能將錯誤引入本來已經測試過的舊代碼，破壞原有的系統。所以，當軟件修改是咱們應儘可能經過擴展的方式來實現，而不是修改原有的代碼。固然實際開發中修改源碼和繼承可能同時存在，具體實現還需開發中自行判斷，保證程序的穩定與拓展，儘可能遵循開閉原則。

3. 里斯替換原則 LSP（Liskov Subsititution Principle）

定義：因此引用其基類的地方都必須能透明的使用其子類 簡單的說就是父類出現的地方均可以替換成其子類，而且程序不會發生任何錯誤和異常。可是反過來是不行的。

使用里斯替換原則須要注意一下幾個問題：

1. 子類須要對外提供的方法必須在父類中聲明，且子類必須實現父類中聲明的全部方法。根據里斯替換原則，程序中使用父類進行定義，若是子類的方法未在父類中聲明，則沒法使用該方法。
2. 里斯替換原則的核心原理是抽象和繼承。所以父類應當設計成接口或者抽象類，讓子類繼承或實現。運行時，子類實例替換父類實例，咱們能夠方便的拓展系統功能，同時無需修改原有子類代碼，新增功能能夠新增子類實現。里氏代換原則是開閉原則的具體實現手段之一。

4. 依賴倒置原則 DIP (Dependence Inversion Principle)

定義：高層模塊不該該依賴底層模塊，二者都應該於抽象。抽象不依賴於細節，細節應該依賴於抽象。

java 語言中的表現就是：模塊間的依賴經過抽象發生，實現類之間不產生直接個關係，其依賴關係經過接口或者抽象類產生。

對於「倒置」的理解，若是不遵循該原則，高層模塊將直接依賴於底層模塊細節。若是遵循改原則，底層模塊細節將依賴於高層模塊依賴的抽象。因此是「依賴倒置」

若是不使用該原則，高層模塊將直接依賴於底層模塊細節。底層模塊細節發生改變可能須要同時修改高層模塊，這樣高層與底層直接耦合，不利於代碼的修改與擴展。

5. 接口隔離原則 ISP（InterfaceSegregation Principle）

定義：類間的依賴關係應該創建在最小的接口上。 接口隔離的原則就是將一些龐大、臃腫的接口拆分紅更小和更具體的接口。目的是爲了下降系統耦合，從而更好的修改與擴展。

6. 迪米特原則 LOD (Law of Demeter)

定義：一個對象應該對其餘對象有最少的瞭解。 也稱爲「最少知識原則」。簡單的說就是，一個類應該對本身須要耦合和調用的類知道的最少，類的內部如何實現與調用者或者依賴者不要緊，調用者或者依賴者只須要知道知道它須要的方法便可。其目的也是爲了下降系統耦合，從而更好的修改與擴展。

小結

瞭解了六大原則不難發現它們的目的都是下降系統耦合，提升內聚保持系統擴展性。 完成應用的開發任務是不難的，咱們如何要保證應用後續升級、維護以後依然保持清晰、靈活、穩定的系統架構纔是最難的。遵循面向對象的六大原則即是邁向靈活軟件之路的第一步。 後續將爲你們介紹設計模式