軟件架構設計的七大原則你知道嘛！！

軟件架構設計有七大原則，分別是：

---

1.開閉原則

2.依賴倒置原則

3.單一職責原則

4.接口隔離原則

5.迪米特法則（最小知道原則）

6.里氏替換原則

7.合成/聚合複用原則

下面分別具體說明：

---

1.開閉原則 ：對擴展開放，對修改關閉

說的是,再設計一個模塊的時候,應當使這個模塊能夠在不被修改的前提下被擴展.

換言之,應當能夠在沒必要修改源代碼的狀況下改變這個模塊的行爲，在保持系統必定穩定性的基礎上，對系統進行擴展。

例如：通常軟件功能的升級就須要符合開閉原則，即不去修改原來的代碼，而是去增長新功能。

---

2.依賴倒置原則 ：實現儘可能依賴抽象，不依賴具體實現。

該原則有如下三點說明

• 一、高層模塊不該該依賴於底層模塊，二者都應該依賴於抽象，
• 二、抽象不該該依賴於細節，即具體實現類。
• 三、細節應該依賴於抽象。

這樣帶來的好處，能夠減小類與類之間的耦合性，提升系統的穩定性，提升代碼的可讀性和可維護性，而且能夠下降修改程序所形成的的風險。

例如：咱們在平常開發中拿到需求以後，通常都是面向接口編程，先設計出頂層，在細節的來設計代碼的結構。（以抽象爲基準比以細節爲基準搭建起來的架構要穩定的多）

---

3.單一職責原則 ：對於一個類而言，應該僅存在一個能夠引發類變化的緣由。

從概念來講可能不大好理解，簡單的來說，就是咱們平時在編程的時候，

會在一個類上添加各類各樣的功能。當將來這些功能須要修改時， 你不得不一遍又一遍的修改這個類，並且有可能致使其餘的功能發生問題， 維護起來很麻煩，很難複用，耦合性很大。

若是咱們將這些功能分別用不一樣的類來實現，進行解耦，後期的需求變動和維護就會互不影響，可以下降類的複雜度，提升可讀性，總的來說就是一個類、接口、方法只負責一項職責

4.接口隔離原則：客戶端不該該依賴它不須要的接口，類之間的依賴關係應該創建在最小的接口上。

這個原則指導咱們在設計接口時應當注意一下幾點：

• 一、一個類對一類的依賴應該創建在最小的接口之上。
• 二、創建單一接口，不要創建功能繁多的總接口。
• 三、儘可能細化接口，接口中的方法儘可能少（不是越少越好，必定要適度）。

該原則符合高內聚低耦合的設計思想，可使類具備很好的可讀性、可擴展性和可維護性。咱們在設計接口的時候，應該多花時間思考，既要考慮到業務模型，還須要爲之後可能發生的變動作出一些預判。

---

5.迪米特法則（最小知道原則）：一個對象應該對其餘對象保持最少的瞭解，儘可能下降類與類之間的耦合。

因爲每一個類儘可能減小對其餘類的依賴，所以，很容易使得系統的功能模塊功能獨立，相互之間不存在（或不多有）依賴關係。迪米特法則不但願類之間創建直接的聯繫。若是有真的須要創建聯繫的，也但願能經過他的友元類來轉達。

迪米特原則主要強調只和朋友交流，不和陌生人說話。出如今成員變量、方法的輸入、輸出參數中的類均可以稱之爲成員朋友類，而出如今方法體內部的類不屬於朋友類 。

---

6.里氏替換原則： 一個軟件實體若是適用一個父類的話，那必定是適用於其子類，全部引用父類的地方必須能透明地使用其子類的對象，子類對象可以替換父類對象，而程序邏輯不變。

即任何基類能夠出現的地方，子類必定能夠出現。里氏代換原則是繼承複用的基石，只有當衍生類能夠替換掉基類，軟件單位的功能不受影響時，基類才能被真正複用，而衍生類也可以在積累的基礎上增長新的行爲，里氏代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。在基類與子類的繼承關係就是抽象化的具體實現，因此里氏代換原則是對實現抽象化的具體步驟的規範。

當知足繼承的時候，父類確定存在非私有的成員，子類確定是獲得了父類的這些非私有成員（假設，父類的成員所有是私有的，那麼子類沒辦法從父類繼承任何成員，也就不存在繼承的額概念了）。既然子類繼承了父類的這些非私有成員，那麼父類對象也就能夠在子類對象中調用這些非私有成員。因此，子類對象能夠替換父類對象的位置。

　　在里氏帶環原則下，當需求有變化時，只需繼承，而別的東西不會改變。因爲里氏代換原則才使得開放封閉稱爲可能。這樣使得子類在父類無需修改就能夠擴展。

---

##### 咱們總結一下：子類能夠擴展父類的功能，但不能改變父類原有的功能。 一、子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。 二、子類中能夠增長本身特有的方法。 三、當子類的方法重載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類方法的輸入參數更寬鬆。 四、當子類的方法實現父類的方法時（重寫/重載或實現抽象方法），方法的後置條件（即方法的輸出/返回值）要比父類更嚴格或相等。

使用里氏替換原則有如下優勢： 一、約束繼承氾濫，開閉原則的一種體現。 二、增強程序的健壯性，同時變動時也能夠作到很是好的兼容性，提升程序的維護性、擴 展性。下降需求變動時引入的風險

做爲一個開發者，有一個學習的氛圍跟一個交流圈子特別重要，這是個人iOS交流圈: 無論你是小白仍是大牛歡迎入駐！！ 分享內容包括逆向安防、算法、架構設計、多線程，網絡進階，還有底層、音視頻、Flutter等等......

本身根據梳理網絡來的的開發經驗總結的學習方法，無償分享給你們。須要的話均可以自行來獲取下載。 +裙：196800191、 或者是+ WX（XiAZHiGardenia）免費獲取！ 獲取面試資料 簡歷模板 一塊兒交流技術 (資源集合)

---

7.合成/聚合複用原則：儘可能使用對象組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟件複用的目的。

換句話說，就是在一個新的對象裏面使用一些已有的對象，使之成爲新對象的一部分，新的對象經過這些對象的委派達到複用已有功能的目的。

該原則可使系統更加靈活，下降類與類之間的耦合度，一個類的變化對其餘類形成的影響相對較少。

總結：學習軟件設計原則，千萬不能造成強迫症。碰到業務複雜的場景，咱們須要隨機應變。

在實際開發過程當中，並非必定要求全部代碼都遵循設計原則，咱們要考慮人力、時間、成本、質量，不是刻意追求完美，

要在適當的場景遵循設計原則，體現的是一種平衡取捨，幫助咱們設計出更加優雅的代碼結構