前言：爲什麼需要僞代碼？
讓不會寫代碼的同志或不同技術領域的童鞋都能看懂，廢話不多說，直接剛實例，直觀的學習六大原則吧~~*[]~(￣▽￣)~*
單一職責原則實例
我們先看按照常規邏輯如何寫代碼,下面是一個圖片加載器的僞代碼：
定義類：圖片加載器
定義下載圖片方法：（一百行代碼）
定義顯示圖片方法：（一百行代碼）
定義從獲取緩存方法：（一百行代碼）
照這麼看，所有功能是實現了，但是呢，代碼三百多行。顯得異常臃腫。當未來我們需要擴展，極爲不方便，比如說。我們需要從內存緩存中讀取圖片，磁盤緩存中讀取圖片。或者網絡緩存讀取圖片。那麼我們就需要繼續累加代碼了。這就導致代碼越堆越多。結果呢，未來某天維護的時候，自己都看不懂自己的代碼了。
單一職責原則
定義：就一個類而言，就一個引起類變換的原因
繼續以圖片加載器爲例，僞代碼如下：
定義圖片加載器類
定義圖片緩存類實例
定義圖片顯示類實例
定義圖片下載類實例
定義下載圖片方法：（圖片下載類實例下載圖片）
定義顯示圖片方法：（圖片顯示類實例加載圖片）
定義從獲取緩存方法：（圖片緩存類實例獲取緩存）
我們可以看到，我們把職責統一劃分，這樣自己做的事情就在自己類中處理，圖片加載器類的代碼明顯變少，且易讀。這就是單一職責原則，自己事情自己做~
開閉原則實例
定義：對擴展開放，對修改關閉
我們代碼經過單一職責原則劃分後將會是如下狀態。
定義圖片加載器類
定義圖片緩存類實例 (內存緩存實現類)
定義圖片顯示類實例
定義圖片下載類實例
定義下載圖片方法：（調用圖片下載類實例下載圖片）
定義顯示圖片方法：（調用圖片顯示類實例加載圖片）
定義從獲取緩存方法：（調用圖片緩存類實例獲取緩存）
現在圖片緩存類是內存緩存，如果這時候需要一個磁盤緩存，那麼我們無疑要替換圖片緩存類實例了，這時候呢，我們就對圖片加載器類修改了。這就違背了我們開閉原則。
開閉原則
只需要把需要替換的實例，使用接口或者抽象類定義，可以通過其他函數進行替換，這樣就不需要修改框架類代碼，實現擴展！
定義圖片加載器類
定義圖片緩存類實例 (抽象類、接口)
定義圖片顯示類實例
定義圖片下載類實例
設置緩存類實例方法：（需要外部替換緩存類實例）
定義下載圖片方法：（調用圖片下載類實例下載圖片）
定義顯示圖片方法：（調用圖片顯示類實例加載圖片）
定義從獲取緩存方法：（調用圖片緩存類實例獲取緩存）
里氏替換原則
定義：父類可以出現的地方，子類一定可以出現。並且不會報錯。（必須父子關係，通過里氏替換原則達到對外開放，對修改關閉。）
筆者看法：里氏替換原則和開閉原則相生相依，因爲開閉原則若想不修改，則必須以子類代替父類方式存在。而里氏替換原則正好是這樣。
依賴倒置原則
高層次模塊定義不依賴低層次模塊實現細節（依賴抽象，不依賴具體實現）
理解：可以看開閉原則代碼，緩存類僅僅是一個接口（父類、高層次對象），而我們使用的時候使用的是實現類（子類、低層次對象）
接口隔離原則
定義：類與類之間的依賴應該建立在最小的接口上，多個接口整合一個完整的系統
我們就以Java的InputStream來舉例
可以看到 InputStream 實現了一個叫做Closeable的接口而這個接口就是一個粒度（只有關閉一個方法）的關閉方法，這樣我們可以做一個工具類。傳入對象是一個Closeable的接口。那麼我們就實現了接口隔離了實現。更加容易擴展
最少知識原則（迪米特原則）
定義：一個類應該對其他類有最少的瞭解。
簡單說：自己類的內容應該是相關性很高的屬性和方法。不需要了解其他類。
這個應該都是大家常犯的一個錯誤，最簡單的一個例子就是 ： URLUtil
相信很多童鞋都和筆者一樣。寫一個URLUtil，然後裏面寫了一大堆的URL，比如這樣：
那我們應該如何去做呢？ 案例走起：
定義一個Base模型類：
Base模型類：
獲取服務器地址方法：返回服務器地址
產品模型類（繼承Base模型類）：
獲取產品方法：（獲取服務器地址，拼接產品URL路徑）
可以看到 上面的僞代碼。產品類的URL就在產品類的內部，其他外部類不需要知道。這就是最少知識原則。
好了 本章內容就這些了。給大家拋出一個問題，最少知識原則、開閉原則、里氏替換原則、接口隔離原則他們定義讀一遍有什麼爭議呢？文章有異議的地方歡迎評論區指出！