設計模式6原則

1.開閉原則，簡言之：對擴展開放，對修改關閉，
2.單一職責原則，一個類只負責一項指責，好比：User是一個職責，Order是一個職責
3.里氏替換原則(LSP)：

3.1子類能夠按需擴展自由功能
3.2不修改父類原有功能。若是是繼承而非實現的時候，少用@override

4.依賴倒轉原則：

引用文字設計模式六大原則（3）：依賴倒置原則
定義
問題由來
解決方案
定       義：高層模塊不該該依賴低層模塊，兩者都應該依賴其抽象；抽象不該該依賴細節；細節應該依賴抽象。

問題由來：類A直接依賴類B，假如要將類A改成依賴類C，則必須經過修改類A的代碼來達成。這種場景下，類A通常是高層模塊，負責複雜的業務邏輯；類B和類C是低層模塊，負責基本的原子操做；假如修改類A，會給程序帶來沒必要要的風險。

解決方案：將類A修改成依賴接口O，類B和類C各自實現接口O，類A經過接口O間接與類B或者類C發生聯繫，則會大大下降修改類A的概率。

依賴倒置原則基於這樣一個事實：相對於細節的多變性，抽象的東西要穩定的多。以抽象爲基礎搭建起來的架構比以細節爲基礎搭建起來的架構要穩定的多。在Java中，抽象指的是接口或者抽象類，細節就是實現類，使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操做，把展示細節的任務交給他們的實現類去完成。

依賴倒置原則的核心思想是面向接口編程，咱們依然用一個例子來講明面向接口編程比相對於面向實現編程好在什麼地方。場景是這樣的，母親給孩子講故事，只要給她（母親）一本書，她就能夠照着書給孩子講故事了。代碼以下：

class Book{

public String getContent(){
    return "好久好久之前有一個阿拉伯的故事......";

}
}

class Mother{

public void narrate(Book book){
    System.out.println("媽媽開始講故事了。");

}
}

public class Client{

public static void main(String[] args){
    Mother mother = new Mother();
    mother.narrate(new Book());

}
}
運行結果：

媽媽開始講故事
好久好久之前有一個阿拉伯的故事......
運行良好，假設有一天，需求變成這樣：不是給書而是給一份報紙，讓這位母親講一下報紙上的故事，報紙的代碼以下：

class Newspaper{

public String getContent(){
   return "林書豪38+7領導尼克斯擊敗湖人......";

}
}
咱們發現這位母親卻辦不到，由於她竟然不會讀報紙上的故事，這太荒唐了，只是將書換成了報紙，竟然要咱們必須修改Mother類才能讀。假如之後需求換成雜誌呢，換成網頁呢？難道每換一次都要咱們修改一次Mother類嗎？這顯然不是最好的設計。緣由就是Mother與Book之間的耦合性過高了，必須下降他們的耦合度才行。

咱們引入一個抽象的接口IReader。讀物，包括咱們的博客文章，只要是帶字的都是讀物。代碼以下：

interface IReader{

public String getContent();

}
Mother類與接口IReader發生依賴關係，而Book和Newspaper都屬於讀物的範疇，他們各自都去實現IReader接口，這樣就符合依賴倒置原則了，代碼修改成：

/**
*讓Newspaper去實現IReader這個接口
*/
class Newspaper implements IReader{

public String getContent(){
    return "林書豪17+9助尼克斯擊敗湖人......";

}
}

/**
*讓Book類也去實現IReader這個藉口
*/
class Book implements IReader{

public String getContent(){
    return "好久好久之前有一個阿拉伯的故事......";

}
}

class Mother{

public void narrate(IReader ireader){
   System.out.println("媽媽開始講故事了");
   System.out.println(ireader.getContent());

}
}

/**
*測試類
*/
public class Client{

public static void main(String[] args){
Mother mother = new Mother();
mother.narrate(new Book);
mother.narrate(new Newspaper());

}
}
運行結果：

媽媽開始講故事
好久好久之前有一個阿拉伯的故事......
媽媽開始講故事
林書豪17+9助尼克斯擊敗湖人......
這樣修改以後，不管之後怎樣擴展Client類，都不須要再去修改Mother類了，這只是一個簡單的例子，實際狀況中，表明高層模塊中的Mother類將負責完成主要的業務邏輯，一旦須要對它進行修改，引入錯誤的風險極大。索引遵循依賴倒置原則能夠下降類之間的耦合性，提升系統的穩定性，下降修改程序形成的風險。

採用依賴倒置原則給多人並行開發帶來了極大的便利，好比上面的例子中，本來Mother類和Book類直接耦合時，Mother必須等Book類編碼完成以後才能夠進行編碼，由於Mother類依賴於Book類。修改後的程序則能夠同時開工，互相不影響，由於Book類和這個Mother類一丁點關係也沒有啊。參與協做開發的人越多，項目越龐大，採用依賴倒置原則的意義也就顯得尤其重要。有個很流行的TDD開發模式就是引來倒置原則最成功的應用。

傳遞依賴關係有三種方式，以上的例子中使用的方法時接口傳遞，另外還有兩種傳遞方式：構造方法的傳遞和setter()方法的傳遞，相信用過Spring框架的，對依賴的傳遞方式必定不會陌生。

在實際編程中，咱們通常須要作到如下三點就OK：

低層模式儘可能都要有抽象類和接口，或者二者都有。
變量的聲明類型儘可能是抽象類和接口。
使用繼承的時間遵循里氏替換原則。

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

做者：Java_Yangxiaoyuan
來源：CSDN
原文：https://blog.csdn.net/java_ya...
版權聲明：本文爲博主原創文章，轉載請附上博文連接！

5.接口隔離原則6.迪米特法則