六原則一法則
- 單一職責原則
- 開閉原則
- 依賴倒轉原則
- 裡氏替換原則
- 接口隔離原則
- 合成聚合複用原則
- 迪米特法則
單一職責原則
一個類隻做它該做的事情。
單一職責原則的核心就是高内聚，即一個 子產品隻完成一項功能。單一職責，顧名思義就是一個類隻有一個職責，隻做一件事情。我們在大學裡學的軟體工程和軟體項目管理中，老師都在強調軟體設計要追求“高内聚、低耦合”，以提高子產品的重用性和移植性，而單一職責原則就很好的說明了高内聚。
開閉原則
一個軟體實體應當對擴充開放，對修改關閉。即軟體實體應盡量在不修改原有代碼的情況下進行擴充。
開閉原則的關鍵就是抽象化，我們在代碼編寫的時候，先利用接口和抽象類建構好一個相對穩定的抽象層，而将具體的功能在實作層中編寫。如果需要修改或擴充系統的行為，無須對抽象層進行任何改動，隻需要增加新的具體類來實作新的業務功能即可，達到在進行功能拓展時無序修改現有代碼的效果，達到開閉原則的要求。
依賴倒轉原則
程式要依賴于抽象接口，不依賴于具體實作。
直白的講就是我們常提到的面向接口程式設計。聲明方法的參數類型、方法的傳回類型、變量的引用類型時，盡可能使用抽象類型而不用具體類型，因為抽象類型可以被它的任何一個子類型所替代。
裡氏替換原則
任何時候都可以用子類型替換掉父類型。
因為子類是增強父類的能力，而不是減少父類的能力，是以用父類型的地方就一定能使用子類型。裡氏替換原則可以檢查繼承關系是否合理，如果一個繼承關系違背了裡氏替換原則，那麼這個繼承關系一定是錯誤的，需要對代碼進行重構。
接口隔原則
接口要小而專，絕不能大而全。
不能把接口設計的過于臃腫和複雜。例如，琴棋書畫就應該分别設計為四個接口，而不應設計成一個接口中的四個方法，因為如果設計成一個接口中的四個方法，那麼這個接口很難用，畢竟琴棋書畫四樣都精通的人還是少數，而如果設計成四個接口，會幾項就實作幾個接口，這樣的話每個接口被複用的可能性是很高的。
合成聚合複用原則
優先使用聚合或合成關系複用代碼。
組合和聚合都是對象模組化中關聯（Association）關系的一種。聚合表示整體與部分的關系，表示“含有”，整體由部分組合而成，部分可以脫離整體作為一個獨立的個體存在。組合則是一種更強的聚合，部分組成整體，而且不可分割，部分不能脫離整體而單獨存在。在類與類之間簡單的說有三種關系，Is-A關系、Has-A關系、Use-A關系，分别代表繼承、關聯和依賴。聚合和合成都屬于關聯關系。
其他大佬那裡看到的一個比較好的例子：
我們需要辦理一張銀行卡，如果銀行卡預設都擁有了存款、取款和透支的功能，那麼我們辦理的卡都将具有這個功能，此時使用了繼承關系：
為了靈活地擁有各種功能，此時可以分别設立儲蓄卡和信用卡兩種，并有銀行卡來對它們進行聚合使用。此時采用了合成複用原則:
迪米特法則
一個對象應該對其他的對象有盡可能少的了解，又叫最少知識原則。
這個具體講指的就是低耦合，由于每個類盡量減少對其他類的依賴，是以，很容易使得系統的功能子產品功能獨立，互相之間不存在（或很少有）依賴關系。設計模式中的門面模式（Facade）和中介模式（Mediator），都是迪米特法則應用的例子。
門面模式（Facade）
其含義時引入一個第三方中介類，這個類集合了多個零部件類的功能，實際功能則委托給這些零部件對象，這個類隻是做為對外統一接口，隻是一個馬甲。
中介模式（Mediator）
其含義是用一個中介對象來封裝一系列的對象互動。中介者使個對象不需要顯示地互相引用，進而使其耦合松散，而且可以獨立地改變它們之間的互動。即通過一個中介類接受所有消息，然後再進行轉發。