原則一：單一職責原則
http://blog.csdn.net/zhengzhb/article/details/7278174
只有邏輯足夠簡單，纔可以在代碼級別上違反單一職責原則；只有類中方法數量足夠少，纔可以在方法級別上違反單一職責原則。
原則二：里氏替換原則
http://blog.csdn.net/zhengzhb/article/details/7281833
Liskov於1987年提出了一個關於繼承的原則“Inheritance should ensure that any property proved about supertype objects also holds for subtype objects.”——“繼承必須確保超類所擁有的性質在子類中仍然成立。”也就是說，當一個子類的實例應該能夠替換任何其超類的實例時，它們之間才具有is-A關係。
繼承包含這樣一層含義：父類中凡是已經實現好的方法（相對於抽象方法而言），實際上是在設定一系列的規範和契約，雖然它不強制要求所有的子類必須遵從這些契約，但是如果子類對這些非抽象方法任意修改，就會對整個繼承體系造成破壞。而里氏替換原則就是表達了這一層含義。
里氏替換原則通俗的來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。它包含以下4層含義：
- 子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
- 子類中可以增加自己特有的方法。
- 當子類的方法重寫父類的方法時，方法的前置條件（即方法的形參）要比父類方法的輸入參數更寬鬆。
- 當子類的方法實現父類的抽象方法時，方法的後置條件（即方法的返回值）要比父類更嚴格。
原則三：依賴倒置原
http://blog.csdn.net/zhengzhb/article/details/7289269
實際情況中，高層模塊的類將負責完成主要的業務邏輯，一旦需要對它進行修改，引入錯誤的風險極大。所以遵循依賴倒置原則可以降低類之間的耦合性，提高系統的穩定性，降低修改程序造成的風險。
在實際編程中，我們一般需要做到如下3點：
- 低層模塊儘量都要有抽象類或接口，或者兩者都有。
- 變量的聲明類型儘量是抽象類或接口。
- 使用繼承時遵循里氏替換原則。
傳遞依賴關係有三種方式，以上的例子中使用的方法是接口傳遞，另外還有兩種傳遞方式：構造方法傳遞和setter方法傳遞。
原則四：接口隔離原則
http://blog.csdn.net/zhengzhb/article/details/7296921
接口隔離原則的含義是：建立單一接口，不要建立龐大臃腫的接口，儘量細化接口，接口中的方法儘量少。也就是說，我們要爲各個類建立專用的接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。在程序設計中，依賴幾個專用的接口要比依賴一個綜合的接口更靈活。接口是設計時對外部設定的“契約”，通過分散定義多個接口，可以預防外來變更的擴散，提高系統的靈活性和可維護性。
採用接口隔離原則對接口進行約束時，要注意以下幾點：
- 接口儘量小，但是要有限度。對接口進行細化可以提高程序設計靈活性是不掙的事實，但是如果過小，則會造成接口數量過多，使設計複雜化。所以一定要適度。
- 爲依賴接口的類定製服務，只暴露給調用的類它需要的方法，它不需要的方法則隱藏起來。只有專注地爲一個模塊提供定製服務，才能建立最小的依賴關係。
- 提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
原則五：迪米特法則（又叫最少知道原則）
http://blog.csdn.net/zhengzhb/article/details/7296930
通俗的來講，就是一個類對自己依賴的類知道的越少越好。也就是說，對於被依賴的類來說，無論邏輯多麼複雜，都儘量地的將邏輯封裝在類的內部，對外除了提供的public方法，不對外泄漏任何信息。迪米特法則還有一個更簡單的定義：只與直接的朋友通信。首先來解釋一下什麼是直接的朋友：每個對象都會與其他對象有耦合關係，只要兩個對象之間有耦合關係，我們就說這兩個對象之間是朋友關係。耦合的方式很多，依賴、關聯、組合、聚合等。其中，我們稱出現成員變量、方法參數、方法返回值中的類爲直接的朋友，而出現在局部變量中的類則不是直接的朋友。也就是說，陌生的類最好不要作爲局部變量的形式出現在類的內部。
原則六：開閉原則
http://blog.csdn.net/zhengzhb/article/details/7296944
開閉原則想表達這樣一層意思：用抽象構建框架，用實現擴展細節。