設計模式的七大原則(1) --單一職責原則

正號先生發表於2019-07-19

前言

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

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

我們踩過的坑,歷代前輩們也踩過。可想而知,通他們多年的踩坑填坑經驗後,所總結出來的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應該儘量的少用,要不耦合會非常嚴重,去看看優秀原始碼也是如此。可以思考思考使用單一職責原則,用類來劃分多分支。

總結

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

相關文章