設計思想學習之六大原則

六大原則

• 開閉原則
• 接口隔離原則
• 迪米特法則
• 依賴倒置原則
• 里氏替換原則
• 單一職責原則

這六種原則相信網上一找一大堆，所以我也就不寫一些公共的定義或者一些書面語，我只談談自己的學習理解。

---

開閉原則

開閉原則（Open Close Principle）：對擴展開放，對修改關閉

很通俗易懂的一個原則，我的理解就是想要擴展功能就加新的類新的代碼，以前老的代碼不要去修改。

可以想想一下類似電腦內存條，內容不夠了就在插一條，如果插口無限，你就可以無限插新的內存條而不是去換老的。

接口隔離原則

接口隔離原則（Interface Segregation Principle）：不依賴不需要的接口，實現最小的依賴。

問題由來

public interface Animal{
    void run();
    void fly();
    void eat();
    void sleep();
}
public class Dog implements Animal{
    void run(){};
    void fly(){};
    void eat(){};
    void sleep(){};
}
public class Bird implements Animal{
    void run(){};
    void fly(){};
    void eat(){};
    void sleep(){};
}
//對於狗來說飛是沒用的，對於鳥來說跑是沒用，但是卻又不得不實現

問題解決
把臃腫的接口拆分，讓他們變小。

public interface Animal{
    void eat();
    void sleep();
}
public interface sky{void fly();}
public interface load{void run();}
public class Dog implements Animal,load{
    void run(){};
    void eat(){};
    void sleep(){};
}
public class Bird implements Animal,sky{
    void fly(){};
    void eat(){};
    void sleep(){};
}

採用接口隔離原則對接口進行約束時，要注意以下幾點：

• 接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。

• 爲依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地爲一個模塊提供定製服務，才能建立最小的依賴關係。

• 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。

迪米特法則

迪米特法則（Law Of Demeter）: 我的理解是不要引入非朋友類，保持最少的瞭解，所以也叫最少知道原則（Least Knowledge Principle 簡寫LKP）

問題由來
在下面的代碼中其實老闆完全不需要與工作有依賴

public class Boss{
    private Secretary secretary=new Secretary ();
    public void arrange(Secretary secretary){
        Work work=new Work();
        secretary.send(work);
    }
}
public class Secretary {
    public void send(Work work){
        System.out.println("傳遞工作任務");
        work.arrangeWork();
    }
}
public class Work{
    public void arrangeWork(){
        System.out.println("實現中國偉大復興");
    }
}

問題解決
遵循迪米特法則

public class Boss{
    private Secretary secretary=new Secretary ();
    public void arrange(Secretary secretary){
        secretary.send();
    }
}
public class Secretary {
    private Work work=new Work();
    public void send(){
        System.out.println("傳遞工作任務");
        work.arrangeWork();
    }
}
public class Work{
    public void arrangeWork(){
        System.out.println("實現中國偉大復興");
    }
}

迪米特法則的初衷是降低類之間的耦合，由於每個類都減少了不必要的依賴，因此的確可以降低耦合關係。

依賴倒置原則

依賴倒置原則（Dependence Inversion Principle）：我的理解是不要去直接依賴底層的模塊，而是去依賴接口，然後底層去實現接口

問題由來
假如我現在正在看有關java方面的書學習java

public void My{
    public void study(JavaBook javaBook){
        System.out.print("正在看");
        javaBook.read();
    } 
}
public void JavaBook{
    public void read(){
        System.out.println("JAVA書籍學習");
    }
}

現在我想學C了，發現還要改動My的方法。

public void CBook{
    public void read(){
        System.out.println("C語言書籍學習");
    }
}

問題解決
抽象出一本書

public interface Book{
    void read();
}
public void JavaBook implements Book{
    public void read(){
        System.out.println("JAVA書籍學習");
    }
}
public void CBook implements Book{
    public void read(){
        System.out.println("C語言書籍學習");
    }
}
public void My{
    public void study(Book book){
        System.out.print("正在看");
        book.read();
    } 
}

我現在就是想看啥書就看啥書了

在實際編程中，我們一般需要做到如下3點：

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

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

里氏替換原則

里氏替換原則（Liskov Substitution Principle）:我的理解是當繼承的時候，儘量不要去重寫父類方法，也不要重載父類的方法。

里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。

反面例子

public class Animal｛
    public void run(){System.out.println("歡快的跑")}
｝
public class Dog extends Animal{
    @Override
    public void run(){System.out.println("二哈")}
}
//本意是想擴展父類的方法輸出：二哈歡快的跑。
//結果卻變成了二哈

它有下面四層含義：

• 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。

• 子類中可以增加自己特有的方法。

• 當子類的方法重載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。

• 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。

單一職責原則

單一職責原則（Single Responsibility Principle）:我的理解是專心只做一件事情。即一個類只負責一項職責。

假如一個類有有兩個職責A和B，而當職責A發生改變並出現出錯，難免會影響到職責B,出現不必要的麻煩。而運用了單一職責的話，把兩個職責分爲兩個類，就算A改動也不會對B產生影響。

遵循單一職責原的優點有：

• 可以降低類的複雜度，一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單的多；

• 提高類的可讀性，提高系統的可維護性；

• 變更引起的風險降低，變更是必然的，如果單一職責原則遵守的好，當修改一個功能時，可以顯著降低對其他功能的影響。

需要說明的一點是單一職責原則不只是面向對象編程思想所特有的，只要是模塊化的程序設計，都需要遵循這一重要原則。