設計模式6大原則

1、單一職責原則(Single Responsibility Principle)

定義：就一個類而言， 應該僅有一個引發它變化的緣由。

單一職責的劃分界限並非那麼清晰，不少時候須要靠我的經驗界定。固然最大的問題就是對職責的定義，什麼是類的職責，以及怎麼劃分類的職責。

2、開放封閉原則（Open Close Principle）

定義：類、模塊、函數等應該是能夠拓展的，可是不可修改。

開閉原則指導咱們，當軟件須要變化時，應該儘可能經過拓展的方式來實現變化，而不是經過修改已有代碼來實現。這裏的「應該儘可能」4個字說明OCP原則並非說絕對不能夠修改原始類的。當咱們嗅到原來的代碼「腐化氣味」時，應該儘早地重構，以便使代碼恢復到正常的「進化」過程，而不是經過集成等方式添加新的實現，這會致使類型的膨脹以及歷史遺留代碼的冗餘。所以，在開發過程當中須要本身結合具體狀況進行考量，是經過修改舊代碼仍是經過繼承使得軟件系統更穩定、更靈活，在保證去除「代碼腐化」的同時，也保證原有模塊的正確性。

3、里氏替換原則（Liskov Substitution Principle）

注：它是開閉原則的具體實現手段之一，它的核心原理是抽象

定義：全部引用基類的地方必須能透明地使用其子類的對象。

里氏替換原則的核心原理是抽象，抽象又依賴於繼承這個特性，在OOP中，繼承的優缺點至關明顯，有點以下： （1）代碼重用，減小建立類成本，每一個子類擁有父類的屬性和方法； （2）子類和父類基本類似，但又與父類有所區別； （3）提升代碼的可拓展性。 繼承的缺點： （1）繼承是侵入性的，只要繼承就必須擁有弗雷的全部屬性和方法； （2）可能形成子類代碼的冗餘、靈活性下降，由於子類必須擁有弗雷的屬性和方法。 開閉原則和里氏替換原則每每是生死相依、不離不棄的，經過里氏替換來達到對擴展的開發，對修改的關閉效果。

4、依賴倒置原則（Dependence Inversion Principle）

注：關係到系統的可拓展性、擁抱變化的能力、開閉原則

定義：高層模塊不該該依賴於低層模塊，二者都應該依賴於抽象。抽象不該該依賴於細節，細節應該依賴於抽象。

java中抽象指接口或抽象類，二者都不能直接被實例化的；細節就是實現類，實現接口或者集成抽象類而產生的也就細節，也就是能夠能夠加上yige 關鍵字new產生的對象。高層模塊就是調用端，低層模塊就是具體實現類。依賴倒置原則在java中表現就是，模塊間依賴經過抽象發生，實現類之間不發生直接依賴關係，其依賴關係是經過接口或者抽象類產生的。若是類與類直接依賴細節，那麼久會直接耦合。如此一來當修改時，就會同時修改依賴者代碼，這樣限制了可拓展性。

5、 接口隔離原則（InterfaceSegregation Principles）

注：最小化， 減小依賴從而下降變動的風險。

定義：一個類對另外一個類的依賴應該創建在最小的接口上。

創建單一接口，不要創建龐大臃腫接口；儘可能細化接口，接口中方法儘可能少。也就是說，咱們要爲各個類創建專用的接口，而不要試圖創建一個很龐大的接口供全部依賴它的類調用。 （1）接口儘可能小，可是要有限度。對接口進行細化能夠提升程序設計的靈活性；可是若是太小，則會形成接口數量過多，使設計複雜化。因此，必定要適度。 （2）爲依賴接口的類定製服務，只暴露給調用的類須要的方法，它不須要的方法則隱蔽起來。只有專一得爲一個模塊提供定製服務，才能創建最小的依賴關係。 （3）提升內聚，減小對外交互。接口方法儘可能少用public修飾。接口是對外的承諾，承諾越少對系統開發越有利，變動風險也會越少。

以上（單一職責、開閉原則、里氏替換、接口隔離、依賴倒置）五個原則被Bob大叔在21世紀早期定義爲SOLID原則。做爲面向對象編程的5個基本原則，當這些原則被一塊兒使用時，它們使得一個軟件系統更清晰、簡單，最大程度地擁抱變化。

6、 迪米特原則（Law of Demeter）也稱最少知識原則

注：經過引入一個合理的第三者下降現有對象之間的耦合度。

定義：一個軟件實體應當儘量少地與其餘實體發生相互做用。

一個類應該對本身須要耦合或者調用的類知道最少， 類的內部如何實現與調用者或者依賴關係越密切，耦合度越大，當一個類發生變化時，對另外一個類的影響也越大。 （1）在類的劃分上，應當儘可能建立鬆耦合的類。類之間的耦合度約低，就越有利於服用。一個處於鬆耦合中的類一旦被修改，則不會對關聯的類形成太大的波及。 （2）在類的機構設計上， 每個類都應當儘可能下降其成員變量和成員函數的訪問權限。 （3）在對其餘類的引用上， 一個類對其餘對象的引用應當降到最低。