總原則：開閉原則
解釋：對擴展開放，對修改關閉。
案例：書店打折
首先定義一個book的接口，其中有getPrice方法，獲取價錢。然後實現類novelBook實現book的接口。在上線一段時間之後，書店打算打折出售小說。
這個時候我們的方案有如下三種：
- 給book接口增加一個打折的方法，但是僅僅有一種書要打折，我們就要求全部種類的書都要實現打折方法，這個方案顯然是行不通的。
- 修改novelbook的getPrice方法，但是我們也有需要獲取原價的需求，這個方案顯然也不是很友好
- 寫一個offNovelBook的類繼承novelBook，增加getoffPrice方法。這個方案可以讓我們在不修改原有系統的基礎上去實現變化。此方案可行。
單一職責
解釋：一個類中只有一種職責，引起類中發生變化的原因也只有一類
案例：手機
在沒有遵循單一職責的時候，我們這樣設計手機。
有兩個接口，分別是音樂播放器接口和拍照接口。手機類實現這兩個接口。如果我對拍照的需求改變了，那麼我會去修改手機類，測試的時候是不是也要測試音樂播放功能。相同的，如果我對音樂播放器的需求發生改變，拍照的功能是否會改變這個真的不好說。
實現單一職責的時候我們是這樣設計手機的。
有兩個接口，分別是音樂播放器接口和拍照接口。還有兩個實體類，分別實現了各自的接口。手機實體類擁有這兩個實體類。那麼我拍照需求改變了，我就去更改拍照的實體類，音樂播放器的需求改變了，我就去修改音樂播放器的實體類，各自互不影響。
附加說明：這個原則是工程師下意識都會遵守的，並不會很難。難就難在需求的變更，導致了原本只有一個職責的類變更爲有兩個或以上的職責。這個時候是否需要遵守這個原則就得見仁見智了。
里氏替換原則
解釋：只有當衍生類可以替換掉基類，軟件單位的功能不受到影響時，基類才能真正被複用，而衍生類也能夠在基類的基礎上增加新
案例：矩形和長方形
定義一個四邊形的接口，他有長和寬兩個屬性。矩形類實現四邊形接口，並且提供計算體積的方法。長方形都繼承矩形類，並且提供計算周長的方法。那麼只要是矩形出現的地方，我們都可以用長方形類來代替，並且不影響使用。
如果不遵守里氏替換原則：
那麼在長方形類繼承矩形類的時候，覆蓋掉計算面積的方法，那麼當子類代替父類的時候，方法會發生變化，這樣就不符合里氏替換原則了。
依賴倒轉原則
解釋：模塊間的依賴通過抽象發生，實現類之間不發生直接的依賴關係，其依賴關係是通過接口或抽象類產生的
案例：司機與汽車
司機有一個開車的方法，參數是奔馳汽車類。這樣司機和奔馳汽車就發生了耦合。如果那一天司機不想開奔馳了，想開寶馬，新建了一個寶馬類，但是司機並不能開寶馬，因爲司機已經和奔馳汽車發生了耦合。
根據依賴倒轉原則是這樣寫的代碼
汽車有一個接口類，司機有一個開車的方法，參數是汽車的接口類。這樣只要讓奔馳和寶馬實現汽車的接口類，司機就可以開奔馳和寶馬了。甚至五菱宏光實現了汽車的接口類，司機還能成爲秋名山的老司機。
接口隔離原則
解釋：接口中不應該存在子類用不到卻必須實現的方法
案例：程序員和網站
假設做網站需要兩個步驟，第一步是前端程序設計，第二步是後端程序設計，那麼設計一個接口，裏面有兩個方法，一個是前端程序設計，一個是後端程序設計。那麼全棧工程師可能就一個人完成了網站的設計。那如果是專注後端的程序員可能就不需要實現前端程序設計了。這就違背了接口隔離原則。
應該這麼設計：設計兩個接口，將前端程序設計和後端程序設計分離開。這就是接口隔離了。這樣就避免了讓後端程序員承擔不實現前端程序設計的風險了。
迪米特原則
解釋：一個軟件實體應當儘可能少的與其他實體發生相互作用。每一個軟件單位對其他的單位都只有最少的知識，而且侷限於那些與本單位密切相關的軟件單位。
案例：
在沒有遵循迪米特原則的時候，我可能和很多人發生交流，因此我會去了解和適應不同的人，迪米特法則告訴我們，我們應該只和密切相關的人發生交流。如圖：
