前言
最近工作中備受打擊，之前設計的很多程式都被老大否決，需要重構，讓我好好看看設計模式。之前對這一塊內容的確不怎麼重視，感覺枯燥無聊又派不上用場。後來沉下心來研究了一番...
我靠，原來如此，之前寫程式碼的時候怎麼這麼傻逼，很多問題其實在一開始設計的時候就能避免。之前寫的都是些什麼鬼。
我們踩過的坑，歷代前輩們也踩過。可想而知，通他們多年的踩坑填坑經驗後，所總結出來的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應該儘量的少用，要不耦合會非常嚴重，去看看優秀原始碼也是如此。可以思考思考使用單一職責原則，用類來劃分多分支。
總結
今天就到這裡，一個一個慢慢吃透，一天進步一點。下一篇我們來看介面隔離原則。