設計模式六大原則
設計模式六大原則
我們遇到什麼困難，也不要怕，微笑着面對他，消除恐懼的最好辦法就是面對恐懼，堅持，纔是勝利，加油！奧利給！😂
1. 單一職責原則
-
定義：就一個類而言，應該僅有一個引起它變化的原因爲。
-
錯誤：開發者在Activity中寫Bean文件、網絡數據處理，甚至 Adapter 也寫在 Activity 中。
-
正解：activity就寫activity；其他的輔助類或者工具類重新寫出來；最好是把activity、service、adapter、beans等文件分類分包裝好；
2. 開放封閉原則
-
定義：類、模塊、函數等應該是可以拓展的，但是不可修改。拓展是開放的，修改是封閉的。
-
正解：面對複雜多變的“需求”；我們應該儘量通過擴展的方式來實現變化，而不是通過修改原有的代碼來實現。
-
舉例：我們要實現一個列表，一開始只有查詢的功能，後來要新增“添加”功能，過幾天又要增加“刪除”功能。
-
錯誤：大多數人的做法是寫一個方法，然後通過傳入不同的值控制方法來實現不同的功能。但是如果又要新增功能，我們還得修改方法。
-
正解：用開發封閉原則解決就是增加一個抽象的功能類，讓添加、刪除和查詢作爲這個抽象功能類的子類。這樣再新增功能，就無須修改原有的類，只需要添加一個功能類的子類實現功能類的方法。
3. 里氏替換原則
-
定義：所有引用基類(父類)的地方必須能透明地使用其子類的對象。
-
註釋：在軟件中將一個基類對象替換成其子類對象，程序將不會產生任何錯誤和異常；反過來不成立;→<類似於多態性的定義>
-
建議：在程序中使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。比如：
可以使用 Object url = "https://blog.csdn.net/liusaisaiV1/article/details/105503549" 代替 String url = "https://blog.csdn.net/liusaisaiV1/article/details/105503549" 在運行時，在對url進行類型判斷； -
注意：
- 子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法；
- 儘量把父類設計爲抽象類或者接口，讓子類繼承父類或實現父接口，並實現在父類中聲明的方法；
4. 依賴倒置原則
-
定義：高層模塊不應該依賴低層模塊，兩者都應該依賴於抽象；抽象不應該依賴於細節，細節應該依賴於抽象；
-
抽象即接口或者抽象類；細節即具體實現類或者new 的對象；<並沒有整明白>
5. 迪米特原則
-
定義：一個軟件實體應當儘可能少地與其他實體發生相互作用。
-
註釋：設計系統時，應該儘量減少對象之間的交互。如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的相互作用；如此當其中某一個模塊發生修改時，就會盡量少地影響其他模塊。
-
正解：
- 類的劃分上，應當儘量創建耦合度低的類，這樣類一旦被修改，則不會較大的影響關聯的類；
- 類的結構設計上，每個類都應當儘量降低其成員變量和成員函數的訪問權限。
- 對其他類的引用上，一個對象對其他對象的引用應當降到最低。
6. 接口隔離原則
-
定義：一個類對另一個類的依賴應該建立在最小的接口上。
-
要爲各個類建立專用的接口，而不要試圖建立一個很龐大的接口供所有依賴它的類調用；建立單一接口，不要建立龐大臃腫的接口；要細化接口，接口中的方法儘量少；
-
注意：
- 對接口進行細化可以提高程序設計的靈活性；但是如果過小，則會造成接口數量過多，使設計複雜化。所以要適度。
- 只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。
- 接口方法儘量少用public修飾。接口是對外的承諾，承諾越少對系統的開發越有利，變更風險也會越少。
設計模式分類
1. 創建型設計模式
- 與對象創建有關；共5種：單例模式、工廠方法模式、抽象工廠模式、建造者模式、原型模式；
單例模式
2. 結構型設計模式
- 共7種：適配器模式、裝飾模式、代理模式、外觀模式、橋接模式、組合模式、享元模式。
3. 行爲型設計模式
- 共11種：策略模式、模板方法模式、觀察者模式、迭代器模式、責任鏈模式、命令模式、備忘錄模式、狀態模式、訪問者模式、中介者模式、解釋器模式。等
總結：
- 大佬劉望舒的博客已經寫得很全面了，作爲學習《進階之光》整理筆記的板塊，實在汗顏；大佬的原文博客: 設計模式.。
- 聲明：本文學習資料來自 劉望舒《Android進階之光》.；如有侵權，請聯繫我立即刪除。