面向對象的七大設計原則

1. 單一職責原則（Single Responsibility Principle）

每個類應該專一於作一件事情。

每個職責都是變化的一個軸線，若是一個類有一個以上的職責，這些職責就耦合在了一塊兒。這會致使脆弱的設計。當一個職責發生變化時，可能會影響其它的職責。另外，多個職責耦合在一塊兒，會影響複用性。例如：要實現邏輯和界面的分離。須要說明的一點是單一職責原則不僅是面向對象編程思想所特有的，只要是模塊化的程序設計，都須要遵循這一重要原則。

 

 

2. 里氏替換原則（Liskov Substitution Principle）

超類存在的地方，子類是能夠替換的。

子類型必須可以替換掉它們的父類型。注意這裏的可以兩字。有人也戲稱老鼠的兒子會打洞原則。

 

全部引用父類的地方必須能透明地使用其子類的對象。子類能夠擴展父類的功能，但不能改變父類原有的功能，即：子類能夠實現父類的抽象方法，子類也中能夠增長本身特有的方法，但不能覆蓋父類的非抽象方法。當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

 

 

3. 依賴倒置原則（Dependence Inversion Principle）

實現儘可能依賴抽象，不依賴具體實現。

高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。中心思想是面向接口編程

 

在實際編程中，咱們通常須要作到以下3點：

1. 低層模塊儘可能都要有抽象類或接口，或者二者都有。

2. 變量的聲明類型儘可能是抽象類或接口。

3. 使用繼承時遵循里氏替換原則。

 

採用依賴倒置原則尤爲給多人合做開發帶來了極大的便利，參與協做開發的人越多、項目越龐大，採用依賴致使原則的意義就越重大。

 依賴倒置原則就是要咱們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。

 

 

4. 接口隔離原則（Interface Segregation Principle）

應當爲客戶端提供儘量小的單獨的接口，而不是提供大的總的接口。

客戶端不該該依賴它不須要的接口；一個類對另外一個類的依賴應該創建在最小的接口上。

 

咱們在代碼編寫過程當中，運用接口隔離原則，必定要適度，接口設計的過大或太小都很差。對接口進行細化能夠提升程序設計靈活性是不掙的事實，可是若是太小，則會形成接口數量過多，使設計複雜化。因此必定要適度。設計接口的時候，只有多花些時間去思考和籌劃，就能準確地實踐這一原則。

 

5. 迪米特法則（Law Of Demeter）

又叫最少知識原則，一個軟件實體應當儘量少的與其餘實體發生相互做用。

即：一個對象應該對其餘對象保持最少的瞭解。若是兩個類沒必要彼此直接通訊，那麼這兩個類就不該當發生直接的相互做用。若是其中一個類須要調用另外一個類的某一個方法的話，能夠經過第三者轉發這個調用。簡單定義爲只與直接的朋友通訊。首先來解釋一下什麼是直接的朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。

 

迪米特法則的初衷是下降類之間的耦合，因爲每一個類都減小了沒必要要的依賴，所以的確能夠下降耦合關係。可是凡事都有度，雖然能夠避免與非直接的類通訊，可是要通訊，必然會經過一個「中介」來發生聯繫。故過度的使用迪米特原則，會產生大量這樣的中介和傳遞類，致使系統複雜度變大。因此在採用迪米特法則時要反覆權衡，既作到結構清晰，又要高內聚低耦合。

 

6. 開閉原則（Open Close Principle）

面向擴展開放，面向修改關閉。

 

更通俗一點講，也就是：軟件系統中包含的各類組件，例如模塊（Modules）、類（Classes）以及功能（Functions）等等，應該在不修改現有代碼的基礎上，去擴展新功能。開閉原則中原有「開」，是指對於組件功能的擴展是開放的，是容許對其進行功能擴展的；開閉原則中「閉」，是指對於代碼的修改是封閉的，即不該該修改原有的代碼。

 

開閉原則具備理想主義的色彩，說的很抽象，它是面向對象設計的終極目標。其餘幾條原則，則能夠看作是開閉原則的實現。咱們要用抽象構建框架，用實現擴展細節。

 

7. 組合/聚合複用原則（Composite/Aggregate Reuse Principle CARP）

儘可能使用合成/聚合達到複用，儘可能少用繼承。原則： 一個類中有另外一個類的對象。

 

及儘可能使用合成/聚合，儘可能不要使用類繼承。換句話說，就是能用合成/聚合的地方，毫不用繼承。

 

爲何要儘可能使用合成/聚合而不使用類繼承？

1. 對象的繼承關係在編譯時就定義好了，因此沒法在運行時改變從父類繼承的子類的實現

2. 子類的實現和它的父類有很是緊密的依賴關係，以致於父類實現中的任何變化必然會致使子類發生變化

3. 當你複用子類的時候，若是繼承下來的實現不適合解決新的問題，則父類必須重寫或者被其它更適合的類所替換，這種依賴關係限制了靈活性，並最終限制了複用性。

 

（C） 房上的貓 。 保留全部權利。
 https://www.cnblogs.com/lsy131479/

如需轉載，請註明出處！！！