設計模式六大原則簡介

這篇文章大概講一下設計模式的六大原則，講解沒有原則的方式是：簡單定義->問題由來->解決方案或者需要注意的地方

1.單一職責原則

定義：不要存在多餘乙個導致類變更的原因（乙個類只負責一項職責）。

問題由來：類t負責兩個不同的職責：職責p1和職責p2。當由於職責p1的需求發生改變而需要修改類t的時候，可能導致執行正常的職責p2的功能發生故障。

注意：其實很多事，我們都會注意功能模組化設計的，都會注意盡量實現介面程式設計，都會注意盡量實現低耦合高內聚，但是所有的這一切都不如需求來的快，所以我們要在職責擴散到我們無法控制的程度之前立刻對**進行重構。

2.黎克特制替換原則（lsp）

定義：子型別能夠完全的替換父型別而程式在功能上不受影響。

問題由來：類a能完成p1功能，現在需要p2功能，那麼類b繼承類a並開展了p2功能，即類b有p1和p2功能，這個時候有可能在擴充套件的時候破壞了p1的功能。

注意：子類不要覆蓋父類已有非抽象方法，這樣會破壞繼承體系，如果非要修改的話，讓子類和父類都繼承更底層的基類

3.依賴倒置原則

定義：高層模組不應該依賴低層模組，二者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象。

問題由來：類a直接依賴類b，加入要將類a改為依賴類c，則必須修改類a的**完成。類a一般是高層模組如客戶端，類b和類c是低層模組，負責基本的原子操作。（依賴的意思就是在類a中宣告了乙個類b的引用，無論是屬性裡面還是形參裡面）

解決辦法：將類b和類c抽象為乙個藉口i，而類a改為依賴藉口i，這樣類a就通過介面i間接與類b和類c發生聯絡，降低類a的修改機率。

注意：a.低層模組盡量要有抽象類或介面或兩者都有

b.變數的宣告型別盡量是抽象類或介面

c.使用繼承是記得要遵循黎克特制替換原則

4.介面隔離原則

定義：客戶端不應該依賴它不需要的介面；乙個類對另乙個類的依賴應該建立在最小的介面上。

問題由來：類a通過介面i依賴類b，而介面i對類a和類b都不是最小介面，而類b必須去實現它們不需要的方法

解決辦法：將這個介面分解為更小的多個介面。至於介面的劃分需要仔細思考的。

5.迪公尺特原則

定義：乙個物件應對其他物件儲存最小的了解。

問題來由：類與類直接的關係越密切，耦合度越大，當乙個類發生改變的時候，對另乙個類的影響越大。

其實就是低耦合高內聚。

6.開發-封閉原則

定義：乙個軟體實體如類、模組和函式應該對擴充套件開發，對修改關閉。

問題由來：在軟體生命週期內，因為變化、公升級和維護等原因需要對軟體原有**進行修改時，可能會給舊**中引入錯誤，也可能會使我們不得不對整個功能進行重構，而且需要原有**經過重新測試。

解決辦法：當軟體需求方式變化的時候，我們進行擴充套件軟體的行為來實現變化，而不是對原有的**進行修改來實現變化。