一、單一職責原則
就一個類而言，應該僅有一個引起它變化的原因。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會削弱或者抑制這個類完成其他職責的能力。這種耦合會導致脆弱他的設計，當變化發生時，設計會遭受到意想不到的破壞；軟件設計真正要做的許多內容就是發現職責並把那些職責相互分離。
二、開放-封閉原則
軟件實體應該可以擴展，但不可修改。該原則是面向對象設計的核心所在，遵循這個原則可以帶來面向對象技術所聲稱的可維護、可擴展、可復用、靈活性好。
設計人員必須對於他設計的模塊應該對哪種變化封閉做出選擇，必須先猜測出最有可能發生的變化種類，然后構造抽象來隔離那些變化。最初編寫程序時假設變化不會發生，當變化發生時，就創建抽象來隔離以后發生的同類變化，拒絕不成熟的抽象。
三、里氏代換原則
子類型必須能夠替換掉它們的父類型。由於子類型的可替換性才使得使用父類類型的模塊在無需修改的情況下就可以擴展。
四、依賴倒轉原則
高層模塊不應該依賴低層模塊，兩個都應該依賴抽象；抽象不應該依賴細節，細節應該依賴抽象。
要針對接口編程，不要針對實現編程。該原則可以說是面向對象設計的標志，編寫時考慮的是如何對抽象編程而不是針對細節編程，即程序中所有的依賴關系都是終止於抽象類或者接口。
五、迪迷特原則（最少知識原則）
如果兩個類不必彼此直接通信，那么這兩個類就不應當發生直接的相互作用；如果其中一個類需要調用另一個類的某一個方法的話，可以通過第三者轉發這個調用。
該原則其根本思想，是強調了類之間的松耦合；類之間的耦合越弱，越利於復用，一個處在弱耦合的類被修改，不會對有關系的類造成波及。在類的結構設計上，每一個類都應當盡量降低成員的訪問權限。
六、合成/聚合復用原則
盡量使用合成/聚合，盡量不要使用類繼承。
聚合表示一種弱的“擁有”關系，體現的是A對象可以包含B對象，但B對象不是A對象的一部分；合成則是一種強的“擁有”關系，體現了嚴格的部分和整體的關系，部分和整體的生命周期一樣。
優先使用對象的合成/聚合將有助於你保持每個類被封裝，並被擊中在單個任務上，這樣類和類繼承層次會保持較小規模，並且不太可能增長為不可控制的龐然大物。
七、UML例圖
‘+’表示public，‘-’表示private，‘#’表示protected；
接口頂端有《interface》顯示，只有兩行；同時另一個表示方法為棒棒糖表示法；
聚合表示一種弱的’擁有’關系，體現的是A對象可以包含B對象，但B對象不是A對象的一部分；
合成是一種強的’擁有’關系，體現了嚴格的部分和整體的關系，部分和整體的生命周期一樣；
繼承關系
實現接口
關聯關系
聚合關系
合成關系
依賴關系
空心三角形+實線
空心三角形+虛線
實線箭頭
空心菱形+實線箭頭
實心菱形+實線箭頭
虛線箭頭
