單一職責原則
一個類而言，應該僅有一個引起它變化的原因。
如果一個類承擔的職責過多，就等於把這些職責耦合在一起，一個職責的變化可能會消弱或者抑制這個類完成其他職責的功能。
軟件設計真正要做的許多內容，就是發現職責並把那些職責相互分離，如果你能夠想到多於一個動機去改變一個類，那麼這個類就具有多個職責，這時就應該考慮類的職責分離。
開發-封閉原則
軟件實體（類，模塊）應該可以擴展，但是不可以修改。
對於擴展是開發的，對於修改是封閉的。
無論模塊多麼的‘封閉’，都會存在一些無法對之封閉的變化。既然不可能完全封閉，設計人員必須對於他設計的模塊應該對哪種變化封閉作出選擇。他必須先猜測最有可能發生變化的類，然後構造抽象隔離。在我們最初編程時，假設變化不發生，當發生時，我們就創建抽象來隔離，即面對需求，對程序的改動是通過增加新代碼進行的，而不是修改原來的代碼。我們希望需求變化發生的越早越好，如果很晚發生變化對軟件的風險、成本、和修改的困難度都會加大。開放-封閉原則是面向對象設計的核心所在，遵循這個原則可以帶來面向對象技術聲稱的巨大好處：可維護，可擴展，可複用、靈活性好。
依賴倒轉原則
1、高層模塊不應該依賴底層模塊，兩個都應該隔離。
2、抽象不應該依賴細節，細節應該依賴抽象。
依賴倒轉其實可以說是面向對象設計的標識，如果編寫時考慮的都是如何針對抽象編程而不是針對細節編程，即編程中所有的依賴關係都終止於抽象類或者接口，那就是面向對象的設計。
里氏代理原則：一個軟件實體如果使用一個父類的話，那麼一定適用其子類，而且它察覺不出父類對象和子類對象的區別。在軟件裏面，子類必須能替換掉他們的父類。子類繼承了父類，所有子類可以以父類的身份出現。只有子類可以替換掉父類，軟件的功能不受影響，父類才能真正的複用，而子類能對父類擴展。正是由於子類可以替換父類，才使得使用父類的模塊在無需修改的情況下就可以擴展。
接口隔離原則：使用多個專門的接口來取代一個統一的接口。
合成複用原則：在系統中應該儘量多使用組合和聚合關聯關係，儘量少使用甚至不使用繼承關係。
迪米特法則：一個軟件實體對對其他實體的引用越少越好，或者說如果兩個類不必彼此直接通信，那麼這兩個類就不應當發生直接的相互作用，而是通過引入一個第二者發生間接交互。