單一職責
一個類只負責完成一個職責或者功能。不要設計大而全的類，要設計粒度小、功能單一的類。單一職責原則是為了實現代碼高內聚、低耦合，提高代碼的復用性、可讀性、可維護性。
不同的應用場景、不同階段的需求背景、不同的業務層面，對同一個類的職責是否單一，可能會有不同的判定結果。實際上，一些側面的判斷指標更具有指導意義和可執行性，比如，出現下面這些情況就有可能說明這類的設計不滿足單一職責原則：
- 類中的代碼行數、函數或者屬性過多；
- 類依賴的其他類過多，或者依賴類的其他類過多；
- 私有方法過多；
- 比較難給類起一個合適的名字；
- 類中大量的方法都是集中操作類中的某幾個屬性。
單一職責原則通過避免設計大而全的類，避免將不相關的功能耦合在一起，來提高類的內聚性。同時，類職責單一，類依賴的和被依賴的其他類也會變少，減少了代碼的耦合性，以此來實現代碼的高內聚、低耦合。但是，如果拆分得過細，實際上會適得其反，反倒會降低內聚性，也會影響代碼的可維護性。
開閉原則的定義：
軟件實體（模塊，類，方法等），應該對擴展開發，對修改關閉。
第一點是，開閉原則並不是說完全杜絕修改，而是以最小的修改代碼的代價來完成新功能的開發。
第二點是，同樣的代碼改動，在粗代碼粒度下，可能被認定為“修改”；在細代碼粒度下，可能又被認定為“擴展”
里式替換：
子類對象能夠替換程序中父類對象出現的任何地方，並且保證原來程序的邏輯行為不變及正確性不被破壞
子類的設計要保證在替換父類的時候，不改變原有程序的邏輯以及不破壞原有程序的正確性。
子類在設計的時候，要遵守父類的行為約定（或者叫協議）。父類定義了函數的行為約定，那子類可以改變函數的內部實現邏輯，但不能改變函數原有的行為約定。這里的行為約定包括：函數聲明要實現的功能；對輸入、輸出、異常的約定；甚至包括注釋中所羅列的任何特殊說明。實際上，定義中父類和子類之間的關系，也可以替換成接口和實現類之間的關系。
接口隔離
- 如何理解“接口隔離原則”？理解“接口隔離原則”的重點是理解其中的“接口”二字。這里有三種不同的理解。如果把“接口”理解為一組接口集合，可以是某個微服務的接口，也可以是某個類庫的接口等。如果部分接口只被部分調用者使用，我們就需要將這部分接口隔離出來，單獨給這部分調用者使用，而不強迫其他調用者也依賴這部分不會被用到的接口。如果把“接口”理解為單個 API 接口或函數，部分調用者只需要函數中的部分功能，那我們就需要把函數拆分成粒度更細的多個函數，讓調用者只依賴它需要的那個細粒度函數。如果把“接口”理解為 OOP 中的接口，也可以理解為面向對象編程語言中的接口語法。那接口的設計要盡量單一，不要讓接口的實現類和調用者，依賴不需要的接口函數。
- 接口隔離原則與單一職責原則的區別單一職責原則針對的是模塊、類、接口的設計。接口隔離原則相對於單一職責原則，一方面更側重於接口的設計，另一方面它的思考角度也是不同的。接口隔離原則提供了一種判斷接口的職責是否單一的標准：通過調用者如何使用接口來間接地判定。如果調用者只使用部分接口或接口的部分功能，那接口的設計就不夠職責單一。
控制反轉
控制： 指的是程序執行流程的控制，反轉指的是在沒有使用框架前，程序員自己控制整個程序的執行，使用框架后，整個程序的執行流程可以通過框架來控制，流程的控制權從程序員反轉到框架
實現控制反轉的方法有很多，除了剛才例子中所示的類似於模板設計模式的方法之外，還有依賴注入等方法，所以，控制反轉並不是一種具體的實現技巧，而是一個比較籠統的設計思想，一般用來指導框架層面的設計。
依賴注入
不通過new()的方式在內部創建依賴類對象，而是將依賴的類對象在外部創建好之后，通過創建函數，函數參數等方式傳遞（或注入）給類使用
通過依賴注入的方式來將依賴的類對象傳遞進來，這樣提高了代碼的擴展性，可以靈活的替換依賴的類。
依賴反轉原則：
高層模塊不要依賴低層模塊，高層模塊和低層模塊應該通過抽象來互相依賴，除此之外，抽象不要依賴具體實現細節，具體實現細節依賴抽象。