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