六大設計原則及其使用場景

構成我們學習最大障礙的是已知的東西，而不是未知的東西

1.單一職責原則

即一個類隻負責一個職責，例如現在比較流行的微服務，就是将一個複雜的耦合性很高的業務，拆分成多個獨立的功能單一的接口，然後通過服務編排的方式實作不同的業務需求；

單一職責的好處：

1. 類的複雜性降低，功能明确，可讀性提高，可維護性和可擴充性提高；
2. 變更引起的風險降低

2.開閉原則

開閉原則指的是對擴充開發，對修改關閉。它的意思是說我們在實作一個新的功能時，我們要想着在原有的基礎上擴充，而不是去修改原有的功能！

例如:我們移動端的應用，随着版本疊代，我們不能強制要求我們的使用者每次都去更新或者協助使用者去更新，那麼就要求新增的功能不允許在原有的接口上修改，而是要在原有的接口上進行擴充。

3.裡氏替換原則

裡氏替換原則是面向對象程式設計的實作基礎，它的意思是所有引用了父類的地方都能被子類所替換，且不會引起任何的異常或錯誤；

例如:如果我們将鴕鳥歸為鳥類，那麼鴕鳥也是鳥的子類，但是鳥類會飛，而鴕鳥不會飛，那麼鴕鳥這個子類就違背了裡氏替換原則。

4.依賴倒置原則

依賴倒置原則指的是針對接口程式設計，而不是面向具體的實作程式設計；它的意思是我們在做一個功能時，應該依賴于高層面的實作，而不是依賴于底層的實作；即高層子產品不應該依賴于底層的子產品，因為底層的子產品的職責單一，不足以應對高層子產品的變動；

例如:我們我們打車從A地點出發前往B地點，我們隻需要預約一個車就可以了，而這個車就是一個頂層的接口，它的實作類可以是各種各樣的車，不同廠商的車，不同顔色的車。我們隻需要依賴于這個頂層的車就可以了，而不是依賴于具體的某一個車，或者車牌号為“xxx”的車，一旦我們依賴于具體的車，那麼這輛車被占用或者發生故障，那麼就會對我們從A到B的行程産生影響。

5.接口隔離原則

接口隔離原則是對接口進行規範限制，它指的是使用多個專門的接口比使用單一的總結口要好，即接口應該是互相隔離的小接口，而不是複雜的大接口；

接口隔離原則包含四個定義：

1. 接口要盡量小，這個小指的是不能違反單一職責原則。
2. 接口要高内聚； 高内聚就是提高接口、類、子產品的處理能力，減少對外的互動。在接口中盡量少公布public方法，接口是對外的承諾，承諾越少對系統的開發越有利，變更的風險也就越少，同時也越有利于降低成本。
3. 定制服務；一個系統或系統内的子產品之間必然會有耦合，有耦合就要有互相通路的接口（并不一定就是Java中定義的Interface，也可能是一個類或單純的資料交換），我們設計時就需要為各個通路者（即用戶端）定制服務。定制服務就是單獨為一個個體提供優良的服務。我們在做系統設計時也需要考慮對系統之間或子產品之間的接口采用定制服務。采用定制服務就必然有一個要求：隻提供通路者需要的方法。
4. 接口設計是有限度的。 接口的設計粒度越小，系統越靈活，這是不争的事實。但是，靈活的同時也帶來了結構的複雜化，開發難度增加，可維護性低，這不是一個項目或産品所期望看到的，是以接口設計一定要注意适度，這個“度”如何來判斷？根據經驗和常識判斷，沒有一個固話或可測量的标準

例如:現在的微服務開發，各種服務間的調用，我們應該隻暴露出對方需要的接口；

6.迪米特法則

迪米特法則又稱最少知識原則，它是指一個類對于另一個類知道的越少越好。它設計的初衷是降低類之前的耦合度，每個類之前的聯系少了，那麼每個類都單獨的處理自己的事，這樣就能降低類之前的耦合性；隻有弱耦合了以後，類的複用率才可以提高。其要求的結果就是産生了大量的中轉或跳轉類，導緻系統的複雜性提高，同時也為維護帶來了難度。

例如:電影中看到的，有些人在遇到強盜時會選擇閉着眼睛不看強盜，因為這樣知道的越少對自己來說越安全！

餘路那麼長，還是得帶着虔誠上路...