Java設計模式_七大原則

簡介

• 單一職責原則。對類來講，即一個類應該只負責一項職責。
• 開閉原則。對擴展開放，對修改關閉。在程序須要進行擴展的時候，不能去修改原有代碼，使用接口和抽象類實現一個熱插拔的效果。
• 里氏替換原則。任何基類能夠出現的地方，子類必定能夠出現。實現抽象的規範，實現子父類相互替換。
• 依賴倒置原則。針對接口編程，依賴於抽象而不依賴於具體。
• 接口隔離原則。下降耦合度，接口單獨設計，相互隔離。
• 最少知道原則（迪米特法則）。一個實體應當儘可能少地與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。
• 合成複用原則。儘可能使用聚合、組合的方式，而不是使用繼承。

---

單一職責原則

對類來講，即一個類應該只負責一項職責。如類A負責兩個不一樣的職責：職責一、職責2。當職責1需求變動而改變A時，可能形成職責2執行錯誤，因此須要將類A的粒度分解爲A一、A2。

開閉原則

一個實體如類，模板和函數應該對擴展開放（服務提供方），對修改關閉（服務使用方）。用抽象構建框架，用實現擴展細節。

• 是編程中最基礎。最重要的設計原則。
• 當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有代碼來實現變化。
• 編程中遵循其餘原則以及使用是設計模式的目的就是遵循開閉原則。

里氏替換原則

若是對每個類型爲 T1的對象 o1，都有類型爲 T2 的對象o2，使得以 T1定義的全部程序 P 在全部的對象 o1 都代換成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。換句話說，全部引用基類的地方必須可以透明的使用其子類對象。

在使用繼承時，遵循里氏替換原則，在子類中儘可能不要重寫父類的方法。

• 子類能夠實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
• 子類中能夠增長本身特有的方法。
• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
• 繼承實際上讓兩個類的耦合度加強了，在適當的狀況下，能夠經過聚合、組合、依賴來解決問題。

依賴倒置原則

高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節，細節應該依賴抽象。即針對接口編程，不要針對實現編程。

• 依賴倒置的中心思想就是面向接口編程。傳遞依賴關係有三種方式，以上的說的是是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞，回憶一下Spring框架。
• 依賴倒置原則是基於這樣的設計理念：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建的架構要比以細節爲基礎的架構要穩定的多。在java中，抽象指的是接口或者抽象類，細節就是具體的實現類。
• 使用接口或抽象類的目的是制定好規範，而不涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。
• 低層模板儘可能都要有抽象類或接口，或者兩個都有，程序穩定性更好。
• 變量的聲明類型儘可能都是抽象類或接口，這樣咱們的變量變量引用和實際對象間就存在一個緩衝層，有利於程序的擴展和優化。
• 繼承時遵循里氏替換原則。

接口隔離原則

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

• 創建單一接口，不要創建龐大臃腫的接口，儘可能細化接口，接口中的方法儘可能少。

最少知道原則（迪米特法則）

一個實體應當儘可能少地與其餘實體之間發生相互做用，使得系統功能模塊相對獨立。

• 一個對象應該對其餘對象保持最少的瞭解。
• 類於類的關係越密切，耦合度越大。
• 通俗的來說，就是一個類對本身依賴的類知道的越少越好。也就是說，對於被依賴的類來講，不管邏輯多麼複雜，都儘可能地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。
• 迪米特法則還有一個更簡單的定義：只與直接的朋友通訊
• 直接朋友：每一個對象都會與其餘對象有耦合關係，只要兩個對象之間有耦合關係，咱們就說這兩個對象之間是朋友關係。耦合的方式不少，依賴、關聯、組合、聚合等。其中，咱們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出如今局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要做爲局部變量的形式出如今類的內部。

合成複用原則

儘可能使用聚合、組合的方式，而不是使用繼承。