1.單一原則。一個類應該有且只有一個變化的原因。單一職責原則將不同的職責分離到單獨的類，每一個職責都是一個變化的中心。需求變化時，將通過更改職責相關的類來體現。如果一個類擁有多於一個的職責，則多個職責耦合在一起，會有多於一個原因來導致這個類發生變化。一個職責的變化可能會影響到其他的職責，另外，把多個職責耦合在一起，影響複用性。
2.里氏替換原則，就是要求繼承是嚴格的is-a關係。所有引用基類的地方必須能透明地使用其子類的對象。在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。例如：我喜歡動物，那我一定喜歡狗，因爲狗是動物的子類；但是我喜歡狗，不能據此斷定我喜歡動物，因爲我並不喜歡老鼠，雖然它也是動物。
3.依賴倒置原則。依賴倒置原則的核心就是要我們面向接口編程，理解了面向接口編程，也就理解了依賴倒置。低層模塊儘量都要有抽象類或接口，或者兩者都有。變量的聲明類型儘量是抽象類或接口。
4.接口分離原則。一個類對另一個類的依賴應該建立在最小的接口上,通俗的講就是需要什麼就提供什麼，不需要的就不要提供。接口中的方法應該儘量少，不要使接口過於臃腫，不要有很多不相關的邏輯方法。
5.多用組合(has-a)，少用繼承(is-a)。如果新對象的某些功能在別的已經創建好的對象裏面已經實現，那麼應當儘量使用別的對象提供的功能，使之成爲新對象的一部分，而不要再重新創建。可以降低類與類之間的耦合程度。
6.開閉原則。對修改關閉，對擴展開放。在軟件的生命週期內，因爲變化，升級和維護等原因需要對軟件原有代碼進行修改，可能會給舊代碼引入錯誤，也有可能會使我們不得不對整個功能進行重構，並且需要原有代碼經過重新測試。解決方案：當軟件需要變化時，儘量通過擴展軟件實體的行爲來實現變化，而不是通過修改已有的代碼來實現。不過這要求，我們要對需求的變更有前瞻性和預見性。其實只要遵循前面5中設計模式，設計出來的軟件就是符合開閉原則的。