前言

最近工作中備受打擊，之前設計的很多程式都被老大否決，需要重構，讓我好好看看設計模式。之前對這一塊內容的確不怎麼重視，感覺枯燥無聊又派不上用場。後來沉下心來研究了一番...

我靠，原來如此，之前寫代碼的時候怎麼這麼傻逼，很多問題其實在一開始設計的時候就能避免。之前寫的都是些什麼鬼。

我們踩過的坑，歷代前輩們也踩過。可想而知，通他們多年的踩坑填坑經驗後，所總結出來的23種設計模式是多麼的寶貴，就是我們的“ONE PIECE” 啊。如果掌握了這個內容，對今後無論是工作中還是面試都非常重要。因此下定決心，一定要熟練掌握這塊內容。記錄學習過程，供自己複習也供大家一起學習。

為什麼要學習設計模式的目的

在前言中我們已經大致說明，我們總結一下，一個良好的程式應該滿足一下六點要求：

1. 可復用性：儘量能重用方法，比如說提取某種工具類。
2. 可讀性：編程具備規範性，閱讀起來不困難。
3. 可擴展性：當你寫好的程式需要添加一個新功能的時候，不能說:不行！非要添加的話我要重構代碼。
4. 穩定性：儘可能少的bug。
5. 高內聚：每個模塊儘可能獨立完成自己的功能，不依賴於模塊外部的代碼。
6. 低耦合：並且模塊之間聯繫越複雜耦合度越低，就不會牽一發而動全身。否則模塊A的bug甚至會導致模塊B無法運行

這是多代前輩們總結出來的編程經驗，如果我們的程式沒有以上特點，就會出現很多BUG。我們要站在巨人的肩膀上。儘量多學習多總結，避免犯“古人”們常犯的錯誤。

設計模式的作用就出來了，設計模式的目的就是為了讓我們的程式具備以上六點特性。

設計模式常用的七大原則

在學習設計模式之前，為了不讓設計模式顯得很模式，我們還必須瞭解一個東西，那就是程式設計七大原則（很多地方說的是六大原則，但還有一個合成復用原則也值得提出來）。

這些原則是指導模式的規則，我會給一些原則附上一個例子，來說明這個原則所要表達的意思，註意，原則是死的，人是活的，所以並不是要你完完全全遵守這些規則，否則為何資料庫會有逆範式，只是在可能的情況下，請儘量遵守。

七大原則分別是：

1. 單一職責原則（Single Responsibility Principle）
2. 介面隔離原則（Interface Segregation Principle）
3. 依賴倒置原則（Dependence Inversion Principle）
4. 里氏替換原則（Liskov Substitution Principle）
5. 開閉原則（Open Close Principle）
6. 迪米特法則（Law Of Demeter）
7. 合成復用原則（Composite/Aggregate Reuse Principle CARP）

單一職責原則

看名字就能知道，我們設計的類要儘可能的只負責一項職責。比說說A類只負責A功能，B類只負責B功能，不要A類既負責A功能又負責B功能。

為什麼要這樣設計？

當A功能需要更新，那麼就得去修改A類。如果此時A還負責B功能，就很有可能修出BUG後導致B功能的正常使用。或者說，想實現B功能卻調用的A功能的介面，這樣會導致程式運行混亂。總結以下幾點：

1. 降低類的複雜度，一個類只負責一項職責。
2. 提高類的可讀性，可維護性。
3. 降低變更引起的風險。
4. 通常情況下，我們應當遵守單一職責原則，只要邏輯足夠簡單，才可以在代碼級別違反單一職責原則：也就是說類中的方法數量足夠少，可以在方法級別保持單一職責原則。下述代碼將會說明。

例如以下代碼：

public class SingleResponsibility1 {
    public static void main(String args[]) throws IOException {
        Computer computer = new Computer();
        computer.add();
    }

}
//讀取配置文件和計算
class Computer{
    public int add() throws NumberFormatException, IOException {
        File file = new File("D:/data.txt");
        BufferedReader br = new BufferedReader(new FileReader(file));
        int a = Integer.valueOf(br.readLine());
        int b = Integer.valueOf(br.readLine());
        return a+b;
    }
}

在這個Computer類中有一個add方法，負責讀取配置文件數字，然後再進行相加。

這個類很明顯違反了單一職責原則，一個類既負責了讀取文件，又負責算數。大家考慮一下這樣設計有沒有什麼問題？

問題諸多，提高代碼可維護性，報錯不好定位，功能耦合。。。

來看看更新後的代碼是什麼樣子的：

public class SingleResponsibility2 {
    public static void main(String args[]) throws IOException {
        readFile readFile = new readFile();
        readFile.read("D:/data.txt");
        Computer2 computer = new Computer2();
        computer.add(readFile.getA(),readFile.getB());
    }

}
//計算
class Computer2 {
    public int add(int a, int b){
        return a + b;
    }
}
//讀取配置文件
class readFile {
    private int a;
    private int b;

    public void read(String path) throws IOException {
        File file = new File(path);
        BufferedReader br = new BufferedReader(new FileReader(file));
        a = Integer.valueOf(br.readLine());
        b = Integer.valueOf(br.readLine());
    }

    public int getA() {
        return a;
    }

    public int getB() {
        return b;
    }
}

通過這樣修改代碼，我們實現了單一職責原則。

這樣就萬無一失了嗎？

當然有時候也不見得，因為如果我們的代碼足夠簡單，這樣設計會提供編寫代碼的成本。並且同時還要修改客戶端代碼。

我們再來看看下麵的代碼：

public class SingleResponsibility3 {
    public static void main(String args[]) throws IOException {
        Computer3 computer = new Computer3();
        computer.read("D:/data.txt");
        computer.add(computer.getA(),computer.getB());
    }

}
//負責讀取配置文件，並且負責計算
class Computer3 {
    private int a;
    private int b;

    public void read(String path) throws IOException {
        BufferedReader br = new BufferedReader(new FileReader(path));
        a = Integer.valueOf(br.readLine());
        b = Integer.valueOf(br.readLine());
    }

    public int getA() {
        return a;
    }

    public int getB() {
        return b;
    }
    
    public int add(int a, int b){
        return a + b;
    }
}

當然這個只是示例代碼，在真正的開發環境也不可能這樣用。我舉這個例子只是想說明如果一個類的方法很少功能邏輯比較簡單。如我們寫的Computer類，只負責讀取兩個數，然後相加。

這樣簡單的類其實就可以在代碼級別違反單一職責原則：也就是說類中的方法數量足夠少，可以在方法級別保持單一職責原則。

還是那句話：人是活的，原則是死的。

一個優秀的代碼if else應該儘量的少用，要不耦合會非常嚴重，去看看優秀源碼也是如此。可以思考思考使用單一職責原則，用類來劃分多分支。

總結

今天就到這裡，一個一個慢慢吃透，一天進步一點。下一篇我們來看介面隔離原則。