本文轉自：http://blog.csdn.net/xiqingnian/article/details/41843885
一、單一職責原則（Chapter3）
（1）就一個類而言，應該僅有一個引起它變化的原因。
（2）如果一個類承擔的職責過多，就等於把這些職責耦合在了一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱的設計，當發生變化時，設計會遭受到意想不到的破壞。
（3）軟件設計真正要做的許多內容，就是發現職責並把那些職責相互分離。
二、開放封閉原則（Chapter4）
（1）軟件實體（類、模塊、函數等等）應該可以擴展，但是不可修改。
| （2）面對需求，對程序的改動是通過增加新代碼進行的，而不是更改現有的代碼。 |
（3）我們希望的是在開發工作展開不久就知道可能發生的變化。查明可能發生的變化鎖等待的時間越長，要創建正確的抽象就越困難。
（4）開放-封閉原則是面向對象設計的核心所在。遵循這個原則可以帶來面向對象技術所聲稱的巨大好處，也就是可維護、可擴展、可複用、靈活性好。
（5）開發人員應該僅對程序中呈現出頻繁變化的那些部分做出抽象，然而，對於應用程序中的每個部分都可以的進行抽象同樣不是一個好主意。拒絕不成熟的抽象和抽象本身一樣重要。
三、依賴倒轉原則（Chapter5）
（1）高層模塊不應該依賴低層模塊。兩個都應該依賴抽象。
（2）抽象不應該依賴細節。細節應該依賴抽象。
（3）依賴倒轉法則是面向對象設計的核心。
| （4） 針對接口編程，而非針對實現編程。 |
四、里氏代換原則（Chapter5）
| （1）子類型應該能夠替換掉它的父類型。 |
（2）正是由於子類型的可替換性才使得使用父類類型的 模塊在無需修改的情況下就可以擴展。
五、迪米特法則（Chapter11）
（1）如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用。如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
（2）迪米特法則的根本思想是強調類之間的鬆耦合。
（3）類之間的耦合越弱，越有利於複用，一個處在弱耦合的類被修改，不會對有關係的類造成波及。
六、合成/聚合複用原則（Chapter22）
儘量使用合成/聚合，儘量不要使用類繼承。
（1）聚合表示一種弱的“擁有”關係，體現的是A對象可以包含B對象，但B對象不是A對象的一部分；
（2）合成表示一種強的“擁有”關係，體現了嚴格的部分和整體的關係，部分和整體的生命週期一樣。
七、敏捷開發原則（Chapter23）
敏捷開發原則告訴我們，不要爲代碼添加基於猜測的、實際不需要的功能。如果不清楚一個系統是否需要命令模式，一般不要急着去實現它，事實上，在需要的時候，通過重構實現這個模式並不困難，只有在真正需要如撤銷/恢復操作等功能時，把原來的代碼重構爲命令模式纔有意義。