本文由@呆代待殆原創，轉載請注明出處。

?

寫在前面：所謂設計原則并不是一定要遵守的法則，只是一種建議，因為保持這些原則本身會有一定代價，若是這些代價超過了帶來的好處就得不償失了，所以一切還是以簡單為準。

?

原則一：分離變與不變的部分。

定義：找出代碼中會發生變化的部分，并將其和保持不變的部分分離。

作用：提升可維護性。將會變化的部分分離后，在以后的修改過程中就不會影響到其他不變的部分。

?

原則二：面向接口編程。

定義：面向接口編程，而不是面向某個實現。

作用：降低耦合。這里的接口有多個含義，并不僅僅只java中的interface，更準確的表達應該是面向超類編程。這樣的話只要接口不發生改變，依賴接口的部分就不用發生改變，我們都知道，接口發生改變的可能性比接口的某個實現發生改變的可能性小很多。

?

原則三：開閉原則（The Open-Closed Principle）。

定義：類需要支持擴展而拒絕修改。

作用：增加可修改性和可維護性。

?

原則四：Dependency Inversion Principle（依賴倒置原則，之后簡稱DIP）。

定義：不要依賴實例（concrete classes）編程，依賴抽象（abstractions，指依賴抽象類和接口）。

關于倒置（inversion）的理解：通常我們的高層組件都會依賴于低層組件（指某個低層具體實例類），而DIP是不允許這樣的，在DIP的指導下，我們會創建一個抽象類，讓它處于高層組件與低層組件之間，打破這種依賴，這時不僅高層組件會依賴于這個抽象類，低層組件會依賴于這個所處位置比它高層的抽象類，所以會出現“倒置”這個說法。

此原則的幾個指導方針（并不是一定要準守，只是在開發的時候當成一個參考而已）

1，不要有指向一個具體實例（concrete class）的引用。

2，不要有從具體實例（concrete class）派生出的類。

3，不要覆蓋父類中已經實現的方法。

4，低層組件盡量都要有共同的接口或者抽象類。

與原則二的區別：比原則二更加嚴格，它增加了高層組件不能直接依賴低層組件這一條。

作用：降低耦合。只要定義好了高層組件和低層組件間的接口，他們的開發可以同步進行，在多人開發中的意義也很大。

?

原則五：最少至少原則（The Principle of Least Knowledge）[又稱迪米特法則（Law of Demeter）]

定義：一個對象應該對其他對象保持最少的了解。

此原則的幾個指導方針

1，只調用自己的成員方法。

2，只調用當做參數傳遞進來的對象的成員方法。

3，只調用自己的方法實例化的對象的成員方法。

4，只調用組合對象（成員變量的一部分）的成員方法。

作用：降低復雜度，提高可維護性。

?

原則六：好萊塢原則（The Hollywood Principle）

定義：別調用我們，我們會調用你。

作用：防止依賴腐敗（dependency rot），當高層組件和低層組件組件相互依賴的時候，通常組件之間的關系會過于復雜，這時，就可以運用這個原則，拒絕低層組件調用高層組件，而是等待高層組件來調用低層組件，這樣可以降低編程的復雜程度。

?

原則七： 單一責任原則（Single Responsibility）

定義：一個類只有一個引起變化的原因

作用：高內聚，提高可維護性。每個類只有一個職責，只有這個職責發生改變的時候這個類才應該被修改。

?

?

參考資料：《Head First 設計模式》

?

轉載于:https://www.cnblogs.com/coffeeSS/p/5413512.html

總結

以上是生活随笔為你收集整理的设计模式-设计原则（Design Principle）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。