單一職責原則
單一職責原則（Single responsibility principle），就一個類而言，應該只有一個引起它變化的原因。
在實際編程中的體現，比如一個類只是某一個事物相關的集合，一個函數只做一件事情，不要在這個函數中編寫一些不想關的邏輯，這樣可以最大程度的提高程序的可維護性，可復用性。
開放-封閉原則
開放-封閉原則，是說軟件實體（類、模塊、函數等等）應該可以擴展，但是不可以修改，即對擴展是開放的，對修改是關閉的。新的需求，應該通過增加新的代碼來完成，而不是修改現有的代碼。絕對的對修改關閉是不可能的，可以預先猜測最有可能發生的變化種類，然後構造抽象來隔離那些變化。
在實際編程中的體現，比如接手了一個復雜的代碼庫，要基於此完成某種功能時，如果一上手就咔咔咔大改裡面的邏輯，不僅不是正確的做法，有時越改越深入，如果不完全理解這個代碼庫的大部分邏輯，就不能完成當前的需求，耽誤了很長時間，老大肯定會不開心的^_^。
依賴倒置原則
1. 高層模塊不應該依賴底層模塊。兩個都應該依賴抽象；
2. 抽象不應該依賴細節。細節應該依賴抽象。
開發程序時，高層模塊調用底層模塊的函數。當要做新項目時，發現高層模塊基本一致，想要復用，但是要換用不同的數據庫或者存儲方式（底層模塊），而高層模塊與底層訪問數據庫的模塊綁定了，無法復用，這就出現了倒置。解決辦法是不管高層模塊還是底層模塊，都應該依賴抽象，具體一點就是接口和抽象類。
在實際生活當中的應用，比如計算機的主板、CPU、內存、硬盤等都是針對接口設計的，如果針對實現來設計，比如某一個型號的主板只支持某一個型號的CPU，這將會大大制約計算機的發展。在實際編程中的應用，比如，一個部門寫了一個lib，其他部門都要使用，那麼這些部門就應該相互溝通好，大家先把接口固定，然後各自編寫自己的程序，只要接口設計的穩定，這些部門之間就可以自己寫自己的程序，不用擔心相互干擾。
裡氏代換原則
子類型必須能夠替換掉它們的父類型。意思是如果一個軟件實體使用的是一個父類的話，那麼一定適用於其子類，而且它察覺不出父類對象和子類對象的區別，即在軟件裡面，把父類都替換成它的子類，程序的行為沒有變化。再通俗點，如果一個方法需要父類對象作為輸入，如果你提供一個子類對象，它也應該正常工作，如果它不能正常工作，那麼這種寫法就違反了裡氏替換原則。
迪米特法則
迪米特法則，如果兩個類不必彼此直接通信，那麼這兩個類就不應該發生直接的相互作用。如果其中一個類需要調用領一個類的某一個方法的話，可以通過第三者轉發這個調用。在類的結構設計上，每一個類都應當盡量降低成員的訪問權限，不需要公開的就不要公開，其根本思想是強調了類之間的松耦合。
