【前言】設計模式的原則是設計模式的需要遵守的規範，設計模式滿足的規則越多那麼這個模式也就越精辟，我們根據設計自己的代碼結構的時候要把遵循這些原則作為前提，否則維護時的代價就是巨大的。
一、單一職責原則
就一個類而言，應該僅有一個引起它變化的原因。
這是什麼意思呢，就想我們如果在一個類裡面包含了很多功能，比如通路資料庫、運算算法等，隻要我們需要換一種資料庫，那我們就必須去修改這個類，是不是聞到了壞代碼的味道，這就違反了我們的開放-封閉原則。
遵循單一原則的優點：
·可以降低類的複雜度，一個類隻負責一項職責，其邏輯肯定要比負責多 項職責簡單的多；
·提高類的可讀性，提高系統的可維護性；
·變更引起的風險降低，變更時必然的，如果單一原則遵循的比較好，那麼可以顯著降低對其他功能的影響。
二、開放=封閉原則
軟體實體可以擴充但是不能修改。
也對是要求我們的軟體實體對擴充開放，對修改關閉。對應到我們學過的内容就是寫一個運算抽象類，然後讓這些加減乘除子類繼承運算類，如果我們想要添加一個取餘的算法隻需要再寫一個子類就行啦，不用對抽象類進行修改。想要運用好開閉原則，就要在剛開始設計的時候就要考慮好，抽象要合理，對需求的變更具有前瞻性和預見性。
三、依賴倒轉原則
抽象不應該依賴細節，細節應該依賴于抽象，針對接口程式設計，不要對實作程式設計；高層子產品不應該依賴底層子產品，兩個都應該依賴抽象。
我覺得要了解依賴倒轉原則主要就是了解面向接口程式設計，我們的目标不是為了實作某些功能，而是去設想有什麼需要的功能，然後編譯為接口，當我們需要實作這些功能的時候隻需要去繼承這些接口就行，而且發生變化時的可擴充性也比較強。
我們常見的電腦主機闆、CPU、記憶體條等都是針對接口程式設計的，如果CPU壞了，我們隻需要換一個新的CPU就可以，對其他元件是沒有影響的。但是如果他們是焊接在一起的，那麼一個損壞了可能所有的元件都不能正常工作了，是以說針對接口程式設計使得靈活性大大增強。
四、裡氏代換原則
一個軟體實體如果使用的是一個父類的話，那麼一定适用于其子類，而且覺察不出父類對象和子類對象的差別。也就是說，在軟體裡面，把父類都替換成它的子類，程式的行為沒有變化。簡單了解：子類型必須能夠替換掉它們的父類型。
裡氏代換原則主要是針對于繼承的，當子類繼承父類的子類必須擁有父類的所有屬性，在此基礎上可以有自己獨特的方法或屬性。我們寫了一個父類是鳥類，父類有一個屬性是飛翔；但是企鵝不會飛，是以企鵝就不能繼承父類，再程式設計的角度來看企鵝不是鳥。
五、迪米特法則（最少知道原則）
如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的互相作用，如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
這是減少耦合的一個原則，感覺和中介者有一點像。舉個栗子，小明和小紅是同僚，小亮和小紅是鄰居，現在小明有東西要給小亮，就可以讓小紅回家的時候帶給小亮，這樣就不用單獨跑一趟了。好像有點不恰當哈，反正根本原則就是抵制強耦合，盡量讓少的類存在耦合關系。
六、合成聚合複用原則
盡量使用合成/聚合關系，盡量不要使用類繼承。
過多的繼承是類與類之間的耦合關系增強，是以我們應該在使用繼承的時候想一下可否使用聚合群組合關系。有限使用對象的組合、聚合有助于保持每個類被封裝，并集中在單個任務上。這樣類和類繼承層次會保持較小規模，并且不太可能會增長成為不可控制的龐然大物。
下面是在網上看到的一個圖檔舉得很不錯分享給大家：（圖來自卡奴達摩的部落格）
【總結】單一職責原則告訴我們實作類要職責單一；裡氏替換原則告訴我們不要破壞繼承體系；依賴倒置原則告訴我們要面向接口程式設計；迪米特法則告訴我們要降低耦合。而開閉原則是總綱，他告訴我們要對擴充開放，對修改關閉。合成聚合複用告訴我們避免過多繼承。