設計模式一共有七大設計原則，其中包括開閉原則，單一職責原則，里氏替換原則，依賴導致原則，接口隔離原則，迪米特法則，合成複用原則。
一、開閉原則（Open Close Principle）
開閉原則是設計模式的總原則，開閉原則簡單來說就是：對擴展開放，對修改關閉。
1. 如何理解“對擴展開放、對修改關閉”？
添加一個新的功能，應該是通過在已有代碼基礎上擴展代碼（新增模塊、類、方法、屬性等），而非修改已有代碼（修改模塊、類、方法、屬性等）的方式來完成。關於定義，我們有兩點要注意。第一點是，開閉原則並不是說完全杜絕修改，而是以最小的修改代碼的代價來完成新功能的開發。第二點是，同樣的代碼改動，在粗代碼粒度下，可能被認定爲“修改”；在細代碼粒度下，可能又被認定爲“擴展”。
2. 如何做到“對擴展開放、修改關閉”？
我們要時刻具備擴展意識、抽象意識、封裝意識。在寫代碼的時候，我們要多花點時間思考一下，這段代碼未來可能有哪些需求變更，如何設計代碼結構，事先留好擴展點，以便在未來需求變更的時候，在不改動代碼整體結構、做到最小代碼改動的情況下，將新的代碼靈活地插入到擴展點上。
很多設計原則、設計思想、設計模式，都是以提高代碼的擴展性爲最終目的的。特別是 23 種經典設計模式，大部分都是爲了解決代碼的擴展性問題而總結出來的，都是以開閉原則爲指導原則的。最常用來提高代碼擴展性的方法有：多態、依賴注入、基於接口而非實現編程，以及大部分的設計模式（比如，裝飾、策略、模板、職責鏈、狀態）
二.單一職責原則（Single Responsibility Principle）
單一職責原則簡單來說就是保證設計類，接口，方法的時做到功能單一權責分明。
1. 如何理解單一職責原則（SRP）？
一個類只負責完成一個職責或者功能。不要設計大而全的類，要設計粒度小、功能單一的類。單一職責原則是爲了實現代碼高內聚、低耦合，提高代碼的複用性、可讀性、可維護性。
2. 如何判斷類的職責是否足夠單一？
不同的應用場景、不同階段的需求背景、不同的業務層面，對同一個類的職責是否單一，可能會有不同的判定結果。實際上，一些側面的判斷指標更具有指導意義和可執行性，比如，出現下面這些情況就有可能說明這類的設計不滿足單一職責原則：
- 類中的代碼行數、函數或者屬性過多；
- 類依賴的其他類過多，或者依賴類的其他類過多；
- 私有方法過多；
- 比較難給類起一個合適的名字；
- 類中大量的方法都是集中操作類中的某幾個屬性。
3. 類的職責是否設計得越單一越好？
單一職責原則通過避免設計大而全的類，避免將不相關的功能耦合在一起，來提高類的內聚性。同時，類職責單一，類依賴的和被依賴的其他類也會變少，減少了代碼的耦合性，以此來實現代碼的高內聚、低耦合。但是，如果拆分得過細，實際上會適得其反，反倒會降低內聚性，也會影響代碼的可維護性。
三、里氏代換原則（Liskov Substitution Principle）
裏式替換原則是用來指導，繼承關係中子類該如何設計的一個原則。理解裏式替換原則，最核心的就是理解“design by contract，按照協議來設計”這幾個字。父類定義了函數的“約定”（或者叫協議），那子類可以改變函數的內部實現邏輯，但不能改變函數原有的“約定”。這裏的約定包括：函數聲明要實現的功能；對輸入、輸出、異常的約定；甚至包括註釋中所羅列的任何特殊說明。
理解這個原則，我們還要弄明白裏式替換原則跟多態的區別。雖然從定義描述和代碼實現上來看，多態和裏式替換有點類似，但它們關注的角度是不一樣的。多態是面向對象編程的一大特性，也是面向對象編程語言的一種語法。它是一種代碼實現的思路。而裏式替換是一種設計原則，用來指導繼承關係中子類該如何設計，子類的設計要保證在替換父類的時候，不改變原有程序的邏輯及不破壞原有程序的正確性。
四、依賴倒轉原則（Dependence Inversion Principle）
這個原則是開閉原則的基礎，具體內容：針對接口編程，依賴於抽象而不依賴於具體。
理解好這個原則需要理解下面幾個概念：
1. 控制反轉
實際上，控制反轉是一個比較籠統的設計思想，並不是一種具體的實現方法，一般用來指導框架層面的設計。這裏所說的“控制”指的是對程序執行流程的控制，而“反轉”指的是在沒有使用框架之前，程序員自己控制整個程序的執行。在使用框架之後，整個程序的執行流程通過框架來控制。流程的控制權從程序員“反轉”給了框架。
2. 依賴注入
依賴注入和控制反轉恰恰相反，它是一種具體的編碼技巧。我們不通過 new 的方式在類內部創建依賴類的對象，而是將依賴的類對象在外部創建好之後，通過構造函數、函數參數等方式傳遞（或注入）給類來使用。
3. 依賴注入框架
我們通過依賴注入框架提供的擴展點，簡單配置一下所有需要的類及其類與類之間依賴關係，就可以實現由框架來自動創建對象、管理對象的生命週期、依賴注入等原本需要程序員來做的事情。
4. 依賴反轉原則
依賴反轉原則也叫作依賴倒置原則。這條原則跟控制反轉有點類似，主要用來指導框架層面的設計。高層模塊不依賴低層模塊，它們共同依賴同一個抽象。抽象不要依賴具體實現細節，具體實現細節依賴抽象
五、接口隔離原則（Interface Segregation Principle）
這個原則的意思是：使用多個隔離的接口，比使用單個接口要好。
1. 如何理解“接口隔離原則”？
理解“接口隔離原則”的重點是理解其中的“接口”二字。這裏有三種不同的理解：
如果把“接口”理解爲一組接口集合，可以是某個微服務的接口，也可以是某個類庫的接口等。如果部分接口只被部分調用者使用，我們就需要將這部分接口隔離出來，單獨給這部分調用者使用，而不強迫其他調用者也依賴這部分不會被用到的接口。
如果把“接口”理解爲單個 API 接口或函數，部分調用者只需要函數中的部分功能，那我們就需要把函數拆分成粒度更細的多個函數，讓調用者只依賴它需要的那個細粒度函數。
如果把“接口”理解爲 OOP 中的接口，也可以理解爲面向對象編程語言中的接口語法。那接口的設計要儘量單一，不要讓接口的實現類和調用者，依賴不需要的接口函數。
2. 接口隔離原則與單一職責原則的區別
單一職責原則針對的是模塊、類、接口的設計。接口隔離原則相對於單一職責原則，一方面更側重於接口的設計，另一方面它的思考角度也是不同的。接口隔離原則提供了一種判斷接口的職責是否單一的標準：通過調用者如何使用接口來間接地判定。如果調用者只使用部分接口或接口的部分功能，那接口的設計就不夠職責單一。
六、迪米特法則，又稱最少知道原則（Demeter Principle）
最少知道原則是指：一個實體應當儘量少地與其他實體之間發生相互作用，使得系統功能模塊相對獨立。
1. 如何理解“高內聚、鬆耦合”？
“高內聚、鬆耦合”是一個非常重要的設計思想，能夠有效提高代碼的可讀性和可維護性，縮小功能改動導致的代碼改動範圍。“高內聚”用來指導類本身的設計，“鬆耦合”用來指導類與類之間依賴關係的設計。所謂高內聚，就是指相近的功能應該放到同一個類中，不相近的功能不要放到同一類中。相近的功能往往會被同時修改，放到同一個類中，修改會比較集中。所謂鬆耦合指的是，在代碼中，類與類之間的依賴關係簡單清晰。即使兩個類有依賴關係，一個類的代碼改動也不會或者很少導致依賴類的代碼改動。
2. 如何理解“迪米特法則”？
不該有直接依賴關係的類之間，不要有依賴；有依賴關係的類之間，儘量只依賴必要的接口。迪米特法則是希望減少類之間的耦合，讓類越獨立越好。每個類都應該少了解系統的其他部分。一旦發生變化，需要了解這一變化的類就會比較少。
七、合成複用原則（Composite Reuse Principle）
合成複用原則是指：儘量使用合成/聚合的方式，而不是使用繼承。
1. 爲什麼不推薦使用繼承？
繼承是面向對象的四大特性之一，用來表示類之間的 is-a 關係，可以解決代碼複用的問題。雖然繼承有諸多作用，但繼承層次過深、過複雜，也會影響到代碼的可維護性。在這種情況下，我們應該儘量少用，甚至不用繼承。
2. 組合相比繼承有哪些優勢？
繼承主要有三個作用：表示 is-a 關係，支持多態特性，代碼複用。而這三個作用都可以通過組合、接口、委託三個技術手段來達成。除此之外，利用組合還能解決層次過深、過複雜的繼承關係影響代碼可維護性的問題。
3. 如何判斷該用組合還是繼承？
儘管我們鼓勵多用組合少用繼承，但組合也並不是完美的，繼承也並非一無是處。在實際的項目開發中，我們還是要根據具體的情況，來選擇該用繼承還是組合。如果類之間的繼承結構穩定，層次比較淺，關係不復雜，我們就可以大膽地使用繼承。反之，我們就儘量使用組合來替代繼承。除此之外，還有一些設計模式、特殊的應用場景，會固定使用繼承或者組合。