Java設計模式六大原則-1
Java設計模式六大原則-1
做Java程式開發的每天都在使用JDK，Spring，SpringMvc，Mybatis，Netty，MINA等框架，但很少有人懂得背後的原理。即使開啟跟下原碼也是一頭霧水，很虐心，最後還是回到使用上，為什麼？難道他們不想了解嗎？當然不是，是因為真心看不懂，當時我工作5年，大大小小的專案做了數不清，但是看這些背後的原理根本就看不懂，或者懂一點，其它全是疑問，最終被虐的也不得不放棄。
因為自己不滿足搬磚的，所以還是下定決心要了解各大框架背後的原理。從認識到這個問題後第6年開始一點一點研究，到現在有七年之餘，基本掌握了背後的核心原理。冰凍三尺非一日之寒，就讓我從六大原則開始吧！
- 單一職責原則：不要存在多於一個導致類變更的原因。通俗的說，即一個類只負責一項職責。
- 里氏替換原則：
定義1：如果對每一個型別為 T1的物件 o1，都有型別為 T2 的物件o2，使得以 T1定義的所有程式 P 在所有的物件 o1 都代換成 o2 時，程式 P 的行為沒有發生變化，那麼型別T2 是型別 T1 的子型別。
定義2：所有引用基類的地方必須能透明地使用其子類的物件。
問題由來：有一功能P1，由類A完成。現需要將功能P1進行擴充套件，擴充套件後的功能為P，其中P由原有功能P1與新功能P2組成。新功能P由類A的子類B來完成，則子類B在完成新功能P2的同時，有可能會導致原有功能
解決方案：當使用繼承時，遵循里氏替換原則。類B繼承類A時，除新增新的方法完成新增功能P2外，儘量不要重寫父類A的方法，也儘量不要過載父類A的方法。
繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），實際上是在設定一系列的規範和契約，雖然它不強制要求所有的子類必須遵從這些契約，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。
繼承作為面向物件三大特性之一，在給程式設計帶來巨大便利的同時，也帶來了弊端。比如使用繼承會給程式帶來侵入性，程式的可移植性降低，增加了物件間的耦合性，如果一個類被其他的類所繼承，則當這個類需要修改時，必須考慮到所有的子類，並且父類修改後，所有涉及到子類的功能都有可能會產生故障。
里氏替換原則通俗的來講就是：子類可以擴充套件父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
- 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類的方法過載父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入引數更寬鬆。
- 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
看上去很不可思議，因為我們會發現在自己程式設計中常常會違反里氏替換原則，程式照樣跑的好好的。所以大家都會產生這樣的疑問，假如我非要不遵循里氏替換原則會有什麼後果？
後果就是：你寫的程式碼出問題的機率將會大大增加。
- 依賴倒置原則：
依賴倒置原則的核心思想是面向介面程式設計，我們依舊用一個例子來說明面向介面程式設計比相對於面向實現程式設計好在什麼地方。場景是這樣的，母親給孩子講故事，只要給她一本書，她就可以照著書給孩子講故事了。程式碼如下：
| class Book{ public String getContent(){ return "很久很久以前有一個阿拉伯的故事……"; } }
class Mother{ public void narrate(Book book){ System.out.println("媽媽開始講故事"); System.out.println(book.getContent()); } }
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介面，這樣就符合依賴倒置原則了，程式碼修改為：
| class Newspaper implements IReader { public String getContent(){ return "林書豪17+9助尼克斯擊敗老鷹……"; } } class Book implements IReader{ public String getContent(){ return "很久很久以前有一個阿拉伯的故事……"; } }
class Mother{ public void narrate(IReader reader){ System.out.println("媽媽開始講故事"); System.out.println(reader.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類。修改後的程式則可以同時開工，互不影響，因為Mother與Book類一點關係也沒有。參與協作開發的人越多、專案越龐大，採用依賴導致原則的意義就越重大。現在很流行的TDD開發模式就是依賴倒置原則最成功的應用。
傳遞依賴關係有三種方式，以上的例子中使用的方法是介面傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞，相信用過Spring框架的，對依賴的傳遞方式一定不會陌生。
在實際程式設計中，我們一般需要做到如下3點：
- 低層模組儘量都要有抽象類或介面，或者兩者都有。
- 變數的宣告型別儘量是抽象類或介面。
- 使用繼承時遵循里氏替換原則。
依賴倒置原則的核心就是要我們面向介面程式設計，理解了面向介面程式設計，也就理解了依賴倒置。
如果同學們有疑問或者想獲取更多資源，可以加“張無忌”老師微信（17091005779），找老師獲取。