1.單一職責原則
2.開放-封閉原則
3.依賴倒轉原則
4.里氏代換原則
5.接口隔離原則
6.迪米特原則
1.單一職責原則
什么是單一職責原則？
單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義為：就一個類而言，應該只有一個引起它變化的原因。
單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則
單一職責原則是最簡單的面向對象設計原則，它用於控制類的粒度大小
通俗一點：
1.就是一個類越復雜，可能被復用的可能性越小
2.類越復雜，變動代碼可能會有意想不到的錯誤。
我認為單一職責的目的其實是為了最大可能的復用。
為什么要復用？舉個栗子：
現在有這么一個servlet，它包含了數據庫的連接，驗證密碼是否正確的數據庫操作，同時有登錄的業務邏輯（當用戶名正確時跳轉主頁，密碼失敗時跳轉登錄頁面）。
咋一看沒什么問題，實現了登錄功能。
現在我們要增加一個功能，修改密碼，只有當舊的密碼正確，才能修改密碼。
老辦法：把登錄的代碼（數據庫連接，驗證密碼是否正確的數據庫操作）粘貼過來，新寫修改密碼的業務邏輯（用戶名正確則可以修改，否則修改失敗）。
其實兩個servlet中只有最后一點業務邏輯操作不同。（登錄/登錄失敗）（修改密碼成功/修改密碼失敗）
看起來也不錯，也實現了功能。
但是現在需求又更改了：
1.數據庫名字更換/連接密碼更改，所有servlet的數據庫的連接都要修改
2.要求只有啟用狀態的的賬號能夠登錄，驗證密碼是否正確的數據庫操作也有兩個地方要修改
沒使用復用的話，一個小改動，所有重復代碼都要改動。
對於沒有使用復用的代碼，維護起來簡直就是災難！
怎么這些代碼可以復用起來？
（一個類越復雜，可能被復用的可能性越小）
（一個類越簡答，功能越單一，可能被復用的可能性越大）
讓他們“單一職責”，功能單一就可以啦
數據庫的連接抽象成一個類，負責數據庫的連接
數據庫操作抽象成一個類，負責對數據操作
servlet中，負責業務邏輯判斷。
如果使用復用，僅需要一點簡單的修改，全局的代碼都能修改。
所以我們設計的類盡可能的職責單一，盡可能的功能單一，這樣才能保證我們能夠順利的復用。
為什么系統橫向分為dao,service,controller三層，微服務則是縱向的將服務進行切分。
目的：
減少代碼的冗余，同時做到易修改。
職責單一，可以復用。