軟體架構設計原則

通常，我們在開發乙個完成專案的時候，總會談到要進行軟體架構設計，那麼為什麼要進行軟體架構設計呢，肯定是為了方便軟體後期的維護性、擴充套件性和易讀性。

軟體開發設計有七大原則：

開閉原則有利於軟體的穩定性和可維護性

依賴倒置原則減少類與類之間的依賴，高層模組與底層模組之間的依賴，實現與抽象

單一職責原則降低類的複雜度，提高**的可讀性和可維護性，降低變更引起的風險。乙個類、介面、方法只負責一項職責。

介面隔離原則多個專門的介面，而不是使用單一的總介面，客戶端不應該依賴它不需要的介面。

1、乙個類對一類的依賴應該建立在最小的介面之上；

2、建立單一介面，不要建立龐大臃腫的介面；

3、盡量細化介面，介面中的方法盡量少（不是越少越好，一定要適度）。

復合高內聚低耦合的設計思想，從而使得類具有更好的可讀性、可擴充套件性和可維護性。對業務模型的理解是非常重要的。

黎克特制替換原則

主要是指子類繼承父類的時候，子類能夠繼承父類的非私有成員變數，也可以重新給父類的非私有成員變數賦值，從而替換父類的屬性值。

引申含義：子類可以擴充套件父類的功能，但不能改變父類原有的功能。

1、子類可以實現父類的抽象功能，但不能覆蓋父類的非抽象方法；

2、子類中可以增加自己特有的方法；

3、當子類的方法過載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類方法的輸入引數更寬鬆；

4、當子類的方法實現父類的方法時（重寫/過載或實現抽象方法），方法的後置條件（即方法的輸

出/返回值）要比父類更嚴格或相等。

優點：1、約束繼承氾濫，開閉原則的一種體現；

2、加強程式的健壯性，同時變更時也可以做到非常好的相容性，提高程式的維護性、擴充套件性。降低

需求變更時引入的風險。

迪公尺特法則（最少知道原則）

類和類之間盡量不要產生依賴關係，如果確實非要有依賴關係，要盡量保證他們的依賴最弱。

比如如果非要有依賴的話，優先使用方法體內的成員變數，入參等關係，而不是方法體內部的類。

乙個物件應該對其他物件有最少的了解。通俗地講，乙個類應該對自己需要耦合或呼叫的類知道得最少，你（被耦合或呼叫的類）的內部是如何複雜都和我沒關係，那是你的事情，我就知道你提供的public方法，我就呼叫這麼多，其他的一概不關心

合成復用原則

當有新的需求，需要建立新的物件時，盡量使用物件的組合/聚合來實現，而少用繼承關係。盡量使用物件組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟體復用的目的。可以使系統更加靈活，降低類與類之間的耦合度，乙個類的變化對其他類造成的影響相對較少。

優點：可以使系統更加靈活，降低類與類之間的耦合。乙個類的變化對其他類的影響較少。

設計**架構時，能夠根據實際情況靈活的選擇適合自己的實際業務場景的原則，加以運用，達到未雨綢繆的效果，當有新需求時，可以很好的擴充套件。