最近在工作中發現自己對設計模式是一知半解，打算認真看一下設計模式相關的書籍，並做一些記錄與大家分享（不要嫌棄我寫的不好，因爲現在的我確實很菜）。
先來看面向對象的六大原則吧
（一） 單一職責原則
（二） 開閉原則
（三） 里氏替換原則
（四） 依賴倒置原則
（五） 接口隔離原則
（六） 迪米特原則
單一職責原則
定義 ： 就一個類而言，應該僅有一個引起它變化的原因。簡單的講呢，就是一個類中應該是一組相關性很高的函數、數據的封裝。
class ImageLoader{
download();
cache();
display();
}
就像上面的代碼一樣我們把所有功能寫到一個類中，隨着我們項目越來越大功能也越來越大，會導致這個類很龐大也很脆弱。這時候可以拆分出來每個功能都有一個單獨的類來完成。
class Cache(){
cache();
}
class Download{
download();
}
就像這樣我們把緩存和下載單獨拿出來 Imageloader只保留顯示的功能，這樣我們的代碼結構就會清晰很多。
開閉原則
定義 軟件中的對象（類、模塊、函數等）應該對於擴展是開放的，但是對於修改是封閉的。 也就是說當軟件需要變化時我們應該儘量通過擴展的方式來實現變化，而不是通過修改已有的代碼來實現。
class MemoryCache{
get();
put();
}
我們有這麼個類給用戶使用
class ImageLoader{
MemoryCache m = new MemoryCache();
display();
}
在我們的ImageLoader中只能使用這個類進行內存緩存。那麼問題來了假如用戶有個需求需要自己實現那該怎麼辦呢，總不能去修改我們之前的代碼吧（可能會對其他地方有影響）。這時候我們可以這樣把get 和 put抽象出來
interface Cache{
put();
get();
}
然後 class MemoryCache implements Cache{
get();
put();
}
現在我們的ImageLoader也要做出改變了
class ImageLoader{
Cache m = new Cache();
display();
m.get();
m.set();
set(Cache m);
}
這樣當我們不想用這個MemoryCache我們可以實現Cache接口去自己實現 然後set就行了 （是不是太囉嗦了）
里氏替換原則
定義 所有引用基類的地方必須能透明使用其子類的對象。 里氏替換原則就是依賴於繼承，多態兩大特性。就兩個字 ： 抽象。
就像之前的緩存類一樣 MemoryCache 可以替換掉 Cache的工作並且還能保證行爲的正確性。
我們把put 和 set 抽象了 這就使我們的緩存類有了擴展的可能，保證了可擴展性。
里氏替換爲我們提供了一個指導原則 也就是建立抽象，通過抽象建立規範，具體實現在運行時替換掉抽象，保證系統的擴展性，靈活性
依賴倒置原則
定義 高層模塊不應該依賴低層模塊，兩者之間都應該依賴抽象
抽象不應該依賴細節(實現類)，細節應該依賴抽象
模塊間的依賴關係通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的。
class ImageLoader{
MemoryCache m = new MemoryCache();
display();
}
這個時候我們的ImageLoader就是依賴了MemoryCache 所以Imageloader 和 MemoryCache有直接的耦合當我們的具體實現需要變化時意味着要同時修改依賴者的代碼,限制了系統的可擴展性。
當產品升級 我們會發現 MemoryCache已經不能滿足需求了 這可怎麼辦呢
其實我們可以不要ImageLoader去依賴MemoryCache這個具體的實現 我們應該依賴Cache這個抽象
就和開閉原則裏一樣 通過set 去替換Cache的工作 這樣系統的擴展性就跟高了 完美的解決了我們之前的問題。
接口隔離原則
定義 客戶端不應該依賴它不需要的接口。類間的依賴關係應該是建立在最小的接口上。
把非常龐大、臃腫的接口拆分成更小和更具體的接口 客戶將會只需知道他們感興趣的方法。
接口隔離原則的目的是系統解開耦合 從而容易重構 更改和重新部署。
interface CUser{
register();
login();
delete();
}
CUser中有個delete但是實際上用戶是用不到的 只有後臺管理員纔有delete的權限所以我們拆分一下。
interface CUser{
register();
login();
delete();
}
interface MUser{
delete();
}
迪米特原則
定義 一個對象應該對其他對象有最少的瞭解。也就是隻和最近的朋友通信.
例如 我們找房子先找中介然後中介把房子提供給我們，我們自己看合不合適 這個過程我們即和中介有交互也和房子有交互，導致我們的工作量很大 顯然不符合我們找中介的原因（就是圖個方便）那這個時候該怎麼辦呢
我們可以這樣 我們把我們的要求直接和中介說 由中介去找房子比對 我們只需要知道中介是否找到了房子就好了 這個過程中呢 我們只是和中介有交互。