Java設計模式原則

1、設計模式原則
一、單一原則

1）下降類的複雜度，一個類只負責一項職責
2）提升類的可讀性，可維護性
3）下降變動引發的風險
4）一般狀況下，咱們應當遵照單一原則，只有邏輯足夠簡單，才能夠在代碼級反單一職責；只有類中方法數量足夠少，能夠在方法級別抱持單一職責原則

二、接口隔離原則

1）將接口細化，減小沒必要要的實現
2）類間的依賴關係應該創建在最小的接口上
3）客戶端不該該依賴它不須要的接口

三、依賴倒轉原則

1）高層模塊不該該依賴底層模塊，兩者都應該依賴其抽象
2）抽象不該該依賴細節，細節應該依賴抽象
3）依賴倒轉（倒置）的中心思想是面向接口編程
4）依賴倒轉原則是基於這樣的設計理念：相對於細節的多邊性，抽象的東西要穩定得多。以抽象爲基礎搭建得框架比以細節爲基礎得框架要穩定得多。在Java中，抽象指的是接口或抽象類，細節就是具體的實現類。
5）使用接口或抽象類的目的是制定好規範，而不涉及具體的操做，把細節的任務交給他們的實現類去完成。

四、里氏替換原則

1）里氏替換原則通俗的來說就是：子類能夠擴展父類的功能，但不能改變父類原有的功能。
2）繼承實際上讓兩個類耦合性加強了，在適當的狀況下，能夠經過聚合、組合、依賴來解決問題。
3）里氏代換原則告訴咱們，在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，若是一個軟件實體使用的是一個子類對象的話，那麼它不必定可以使用基類對象。
4）里氏代換原則是實現開閉原則的重要方式之一，因爲使用基類對象的地方均可以使用子類對象，所以在程序中儘可能使用基類類型來對對象進行定義，而在運行時再肯定其子類類型，用子類對象來替換父類對象。

五、開閉原則

1）一個軟件如類、模塊、函數應該對擴展開放，對修改關閉。用抽象構建框架，用實現擴展細節。
2）當軟件須要變化時，儘可能經過擴展軟件實體的行爲來實現變化，而不是經過修改已有的代碼來實現變化。
3）編程中遵循其餘原則，以及使用設計模式的目的就是遵循開閉原則。

六、迪米特法則

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

核心：鬆耦合設計