一、設計模式原則：
1、單一職責原則：
具體描述：應該有且僅有一個原因引起類的變更，即一個方法儘可能只做一件事，儘可能只實現一個功能，而接口儘可能只負責一類功能描述，而類的設計儘量做到只有一個原因引起變化。
實現好處：
降低類複雜性，實現什麼職責都有清晰明確的定義，提高了可讀性，更進一步地提高可維護性，且降低了變更引起的風險。因爲一個變化只有一個原因引起，所以變化引起的變更只修改一個地方便可。
2、里氏替換原則：
具體描述：
所有引用基類的地方必須能透明地使用其子類的對象。即只要父類能出現的地方，子類就可以出現，且替換爲子類不會發生任何錯誤或異常，而使用者可能根本不需要知道是父類還是子類但是反過來就不可以，有子類出現的地方，父類未必可以適應。
一般，子類必須完全實現父類的方法，但子類可以有自己的個性。
實現好處：
使用里氏替換原則的目的是增強程序的健壯性，版本升級時也可以保持非常好的兼容性，即使增加子類，原有的子類還是可以繼續運行，在實際應用中，每個子類對應不同的業務含義，使用父類作爲參數，傳遞不同的子類則可以完成不同的業務邏輯。當然，要使用子類的“個性化”業務邏輯，必須創建子類的對象，不過採用里氏替換原則設計類時，應儘量避免子類的“個性化”。
注意：覆蓋或實現父類的方法時，輸入參數可以被放大，所以應該使子類中的方法的前置條件必須與超類中被覆寫的方法的前置條件相同或更寬。
覆寫或實現父類的方法使輸出結果可以被縮小。
3、依賴倒置原則：
具體描述：高層模塊不應該依賴底層模塊，兩者都應該依賴其抽象，抽象不該依賴實現細節，細節應該依賴於抽象，即，模塊間的依賴通過抽象發生，實現類之間不發生直接依賴關係，其依賴關係式通過接口或抽象類產生，而接口或抽象類不依賴於實現類，實現類則依賴於接口或抽象類。
對象的依賴關係有以下方式來傳遞：
A、構造函數傳遞依賴對象，即在類中通過構造函數聲明依賴對象。
B、通過函數傳遞，即將接口作爲參數來傳遞
C、接口聲明對象依賴，即通過聲明接口來產生依賴
一般實現：
A、每個類儘量都有接口或抽象類或者抽象類和接口兩者都具備
B、變量的表面類型儘可能是接口或者抽象類
C、任何類都不應從具體的實現類派生
D、儘量不要覆寫基類的方法
E、結合里氏替換原則使用，即接口負責定義public屬性和方法，並且聲明與其他對象的依賴關係，抽象類負責公共構造函數的實現，實現類準確的實現業務邏輯，同時在適當的時候對父類進行細化，但儘量避免子類的“個性化”。
一般在實際項目中，對大型的項目採用依賴倒置原則可以讓維護輕鬆，擴展容易簡單。
4、接口隔離原則：
具體描述：
客戶端不應該依賴它不需要的接口，儘可能的保持接口的純潔性，而類間的依賴關係應該建立在最小的接口上，即建立單一的接口，使接口儘量細化，同時接口中的方法儘量少。
一般實現：
A、接口要儘量的小，但不能違反單一職責
B、接口要高內聚，即提高接口、類、模塊的處理能力，減少對外的交互，使其各司其職，但又相互配合。即在接口中儘量少公佈子類的public方法，接口是對外的承諾，承諾越少對系統開發越有利，變更的風險也就越少，同時有利於降低成本。
C、定製服務，即單獨爲一個個體提供有利的服務，具體點就是隻提供訪問者需要的方法。
D、接口設計的粒度是有限度的，在可維護和開發的前提下，儘可能地使設計粒度小，從而使系統更靈活。
一般在實際項目中，接口和類儘量使用原子接口或原子類來組裝，使一個接口只服務於一個子模塊或業務邏輯，通過業務邏輯壓縮接口中的public方法，時常回顧接口，儘量減小其粒度，但若已經被耦合化，或過多耦合的接口，儘量去修改，但若變更風險太大，則嘗試用適配器模式進行轉化處理。不過也不要生搬亂套，要了解環境，拒絕盲從，深入業務邏輯，針對業務邏輯設計接口。
5、迪米特法則：
具體描述：
一個對象應該對其他對象有最少的瞭解，或一個類應該對自己需要耦合或調用的類知道得最少。
一般實現：
對象間，只和相互之間直接耦合的類通信，在設計時應該反覆衡量是否可以再減少Public方法和屬性，是否可以改爲其他的諸如private,protected等訪問權限，是否可以加上final等。如果一個方法放在本類中，即不增加類間關係，也對本類不產生負面影響，就放置在本類中。謹慎使用Serializable,迪米特法則的核心觀念就是類間的解耦，弱耦合，類的複用率纔可以提高，但解耦就意味和產生中專或跳轉類，同時是系統的複雜性提高，同時也維護帶來難度，所以使用此法則時需反覆權衡，即做到讓結構清晰，又做到高內聚低耦合。
6、開閉原則：
具體描述：
一個軟件實體如類、模塊和函數應該對擴展開發，對修改關閉。
一般實現：
儘可能使用擴展軟件實體（項目或軟件產品中按照一定的邏輯規劃劃分的模塊，或抽象和類，方法），而不是通過修改已有的代碼來完成變化，也就是說在設計時就該預留或提供可擴展的接口，或方法，一般的變化可歸納爲邏輯變化，子模塊變化，可見視圖變化。
開閉原則的好處：
A、對測試的影響：新增加的類，新增加的測試方法，只要保證新增加的類的正確性就好。
B、提高複用性
C、提高維護性
如何使用：
A、抽象約束，即通過接口或抽象類約束擴展，對擴展進行邊界界定，不允許出現在接口或抽象類中不存在的public方法，同時參數類型、引用類型儘量使用接口或抽象類，而不是實現類，在設計時確保抽象層的穩定性，一旦確定了，就不可以改了。
B、元數據控制模塊行爲，即用描述環境和數據的數據，或配置參數，參數可以從文件或數據庫中獲得。
C、制定項目章程：團隊間制定相關規範，使成員必須或儘可能遵守。
D、封裝變化：將相同的變化封裝到一個接口或抽象類中，將不同的變化封裝到不同的接口或抽象類中，不該有兩個不同的變化出現在同一個接口後抽象類中。