軟體架構設計有七大原則，分別是：
1.開閉原則
2.依賴倒置原則
3.單一職責原則
4.介面隔離原則
5.迪公尺特法則（最小知道原則）
6.黎克特制替換原則
7.合成/聚合復用原則
下面分別具體說明：
1.開閉原則：對擴充套件開放，對修改關閉
說的是,再設計乙個模組的時候,應當使這個模組可以在不被修改的前提下被擴充套件.
換言之,應當可以在不必修改源**的情況下改變這個模組的行為，在保持系統一定穩定性的基礎上，對系統進行擴充套件。
例如：一般軟體功能的公升級就需要符合開閉原則，即不去修改原來的**，而是去增加新功能。
2.依賴倒置原則：實現盡量依賴抽象，不依賴具體實現。
該原則有以下三點說明
1、高層模組不應該依賴於底層模組，兩者都應該依賴於抽象，
2、抽象不應該依賴於細節，即具體實現類。
3、細節應該依賴於抽象。
這樣帶來的好處，可以減少類與類之間的耦合性，提高系統的穩定性，提高**的可讀性和可維護性，並且可以降低修改程式所造成的的風險。
例如：我們在日常開發中拿到需求之後，一般都是面向介面程式設計，先設計出頂層，在細節的來設計**的結構。（以抽象為基準比以細節為基準搭建起來的架構要穩定的多）
3.單一職責原則 ：對於乙個類而言，應該僅存在乙個可以引起類變化的原因。
從概念來說可能不大好理解，簡單的來講，就是我們平時在程式設計的時候，會在乙個類上新增各種各樣的功能。當未來這些功能需要修改時，你不得不一遍又一遍的修改這個類，而且有可能導致其他的功能發生問題，維護起來很麻煩，很難復用，耦合性很大。
如果我們將這些功能分別用不同的類來實現，進行解耦，後期的需求變更和維護就會互不影響，能夠降低類的複雜度，提高可讀性，總的來講就是乙個類、介面、方法只負責一項職責
4.介面隔離原則：客戶端不應該依賴它不需要的介面，類之間的依賴關係應該建立在最小的介面上。
這個原則指導我們在設計介面時應當注意一下幾點：
1、乙個類對一類的依賴應該建立在最小的介面之上。
2、建立單一介面，不要建立功能繁多的總介面。
3、盡量細化介面，介面中的方法盡量少（不是越少越好，一定要適度）。
該原則符合高內聚低耦合的設計思想，可以使類具有很好的可讀性、可擴充套件性和可維護性。我們在設計介面的時候，應該多花時間思考，既要考慮到業務模型，還需要為以後可能發生的變更做出一些預判。
5.迪公尺特法則（最小知道原則）：乙個物件應該對其他物件保持最少的了解，盡量降低類與類之間的耦合。
由於每個類儘量減少對其他類的依賴，因此，很容易使得系統的功能模組功能獨立，相互之間不存在（或很少有）依賴關係。迪公尺特法則不希望類之間建立直接的聯絡。如果有真的需要建立聯絡的，也希望能通過他的友元類來轉達。
迪公尺特原則主要強調只和朋友交流，不和陌生人說話。出現在成員變數、方法的輸入、輸出引數中的類都可以稱之為成員朋友類，而出現在方法體內部的類不屬於朋友類
。6.黎克特制替換原則：乙個軟體實體如果適用乙個父類的話，那一定是適用於其子類，所有引用父類的地方必須能透明地使用其子類的物件，子類物件能夠替換父類物件，而程式邏輯不變。
即任何基類可以出現的地方，子類一定可以出現。黎克特制代換原則是繼承復用的基石，只有當衍生類可以替換掉基類，軟體單位的功能不受影響時，基類才能被真正復用，而衍生類也能夠在積累的基礎上增加新的行為，黎克特制代換原則是對「開-閉」原則的補充。實現「開-閉」原則的關鍵步驟就是抽象化。在基類與子類的繼承關係就是抽象化的具體實現，所以黎克特制代換原則是對實現抽象化的具體步驟的規範。
當滿足繼承的時候，父類肯定存在非私有的成員，子類肯定是得到了父類的這些非私有成員（假設，父類的成員全部是私有的，那麼子類沒辦法從父類繼承任何成員，也就不存在繼承的額概念了）。既然子類繼承了父類的這些非私有成員，那麼父類物件也就可以在子類物件中呼叫這些非私有成員。所以，子類物件可以替換父類物件的位置。
在黎克特制帶環原則下，當需求有變化時，只需繼承，而別的東西不會改變。由於黎克特制代換原則才使得開放封閉稱為可能。這樣使得子類在父類無需修改就可以擴充套件。
我們總結一下：子類可以擴充套件父類的功能，但不能改變父類原有的功能。
1、子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2、子類中可以增加自己特有的方法。
3、當子類的方法過載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類方法的輸入引數更寬鬆。
4、當子類的方法實現父類的方法時（重寫/過載或實現抽象方法），方法的後置條件（即方法的輸出/返回值）要比父類更嚴格或相等。
使用黎克特制替換原則有以下優點：
1、約束繼承氾濫，開閉原則的一種體現。
2、加強程式的健壯性，同時變更時也可以做到非常好的相容性，提高程式的維護性、擴
展性。降低需求變更時引入的風險
7.合成/聚合復用原則：盡量使用物件組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟體復用的目的。
換句話說，就是在乙個新的物件裡面使用一些已有的物件，使之成為新物件的一部分，新的物件通過這些物件的委派達到復用已有功能的目的。
該原則可以使系統更加靈活，降低類與類之間的耦合度，乙個類的變化對其他類造成的影響相對較少。
總結：學習軟體設計原則，千萬不能形成強迫症。碰到業務複雜的場景，我們需要隨機應變。
在實際開發過程中，並不是一定要求所有**都遵循設計原則，我們要考慮人力、時間、成本、質量，不是刻意追求完美，
要在適當的場景遵循設計原則，體現的是一種平衡取捨，幫助我們設計出更加優雅的**結構
軟體設計原則（七大原則）
本片是自己在工作閒餘時間學習軟體設計模式所獲，在這裡歸納總結，如有不足請多多指教 說到軟體設計原則，可能很多人都會和軟體設計模式混淆，尤其是對剛工作不久的童鞋，其實軟體設計原則只是我們在軟體設計中對軟體架構，各模組之間松耦合，可重用性的一種總結的抽象。而軟體設計模式傾向於軟體架構方面，是站在全域性看...
軟體設計七大原則
軟體設計的七大原則 設計模式遵循的一般原則 1.開 閉原則 open closed principle,ocp 乙個軟體實體應當對擴充套件開發,對修改關閉.說的是,再設計乙個模組的時候,應當使這個模組可以在不被修改的前提下被擴充套件.換言之,應當可以在不必修改源 的情況下改變這個模組的行為，在保持系...
軟體設計七大原則
一 開閉原則定義 乙個軟體實體如類 模組函式應該對擴充套件開放，對修改關閉。是其他原則的基礎或者說是總宗旨，其他原則可以說是此原則的乙個延伸。說人話 不修改現有 的基礎上，去新增功能 二 依賴倒置原則定義 高層模組不應該依賴低層模組，二者都應該依賴其抽象。抽象不應該依賴細節 細節應該依賴抽象。說人話...