買 設計模式 這本書已經快半年了，看著嶄新的書，心裡還有很愧疚的，趁著過年，沒啥開發任務。就把最近零零碎碎的知識總結下。

面向物件的六大原則，一些在平常開發中，跟著老大的風格寫程式碼，無意識中肯定遵守了一些原則，只是意識中知道這樣寫程式碼很有調理。具體為什麼，不太清楚。

1、優化程式碼的第一步 —— 單一職責原則

2、讓程式更加穩定，靈活 —— 開閉原則

3、構建擴充套件性更好的系統 —— 里氏替換原則

4、讓專案擁有變化的能力 —— 依賴倒置原則

5、系統有更高的靈活性 —— 介面隔離原則

6、更好的可擴充套件原則 —— 迪米特原則

我可能分別使用幾篇來介紹幾個原則，如果是面試裝逼，我感覺記住這6個名詞應該就可以應付過去，如果想要更瞭解六大原則，那麼最好去買一本 設計模式這本書。肯定比看我的部落格詳細，學到的全。我呢，只是在這裡打發下時間，強迫自己看幾頁書，為明年跳槽增加點 砝碼。

單一職責原則

就一個類而言，應該僅有一個引起它變化的原因， 一個類中應該是一組相關性很高的函式，資料的封裝。

這個原則是最好理解，也是具有爭議的一個原則。因為沒有具體的尺度。取決去你雄辯能力。

例如：一個載入圖片功能。

新手：寫一個圖片載入類， 

有點責任的：可能會考慮下圖片的快取問題，優化一下。

知道單一原則的人：會把載入圖片放在一個類中，處理圖片快取放在一個類中。

開閉原則

軟體中的物件 模組 類 函式 應該對於擴充套件是開放，但是對於修改是封閉的。

程式一旦開發完成，程式中一個類的實現只應該因錯誤而被修改，，新的或者改變的特性應該通過新建不同的類實現，新建的類可以通過整合的方式來重用原類中程式碼。

再開發中，有點扯淡。但是在與修改外包的程式碼，想不被各種坑爹，你最好遵循這個開閉原則。我就是被坑了無數次。。。。。。。

里氏替換原則

所有引用積累的地方必須能透明地使用其子類物件。——這個顯得比較牛逼，所有字我都認識，但是組成句子我就不懂了。

依賴倒置原則

高層模組不應該依賴底層模組，兩者都應該依賴其抽象；

抽象不應該依賴細節；

細節應該依賴抽象；

介面隔離原則

客戶端不應該依賴它不需要的介面。

類與類之間的依賴關係應該建立在最小的介面上。

迪米特原則

一個物件應該對其他物件有最少的瞭解。

知難行易——成功祕訣是堅持不懈

知易行難——成功祕訣是腳踏實地