開閉原則（Open-Closed Principle）
定義： 開閉原則是指一個軟件實體如類、模塊和函數應該 對擴展開放，對修改關閉。所謂的開閉，也正是對擴展和修改兩個行爲的一個原則。強 調的是用抽象構建框架，用實現擴展細節。
優點： 可以提高軟件系統的可複用性及可維護性。 開閉原則，是面向對象設計中最基礎的設計原則。它指導我們如何建立穩定靈活的系統， 例如：我們版本更新，我儘可能不修改源代碼，但是可以增加新功能。
依賴倒置原則（Dependence Inversion Principle）
定義： 依賴倒置原則是指設計代碼結構時，高層模塊不應該依賴底層模塊，二者都應該依賴其抽象。抽象不應該依賴細節；細節應該依賴 抽象。
優點： 通過依賴倒置，可以減少類與類之間的耦合性，提高系統的穩定性，提高代碼的 可讀性和可維護性，並能夠降低修改程序所造成的風險。
大家要切記：以抽象爲基準比以細節爲基準搭建起來的架構要穩定得多，因此大家在拿 到需求之後，要面向接口編程，先頂層再細節來設計代碼結構。
單一職責原則（Simple Responsibility Pinciple）
定義 ： 單一職責是指不要存在多於一個導致類變更 的原因。假設我們有一個 Class 負責兩個職責，一旦發生需求變更，修改其中一個職責的 邏輯代碼，有可能會導致另一個職責的功能發生故障。這樣一來，這個 Class 存在兩個導 致類變更的原因。如何解決這個問題呢？我們就要給兩個職責分別用兩個 Class 來實現， 進行解耦。後期需求變更維護互不影響。
總 體 來 說 就 是 一 個Class/Interface/Method 只負責一項職責。
優點： 這樣的設計，可以降低類的複雜度，提高類的 可 讀 性 ， 提 高 系 統 的 可 維 護 性 ， 降 低 變 更 引 起 的 風 險 。
接口隔離原則（Interface Segregation Principle）
定義： 接口隔離原則是指用多個專門的接口，而不使用單一的總接口，客戶端不應該依賴它不需要的接口。這個原則指導我們在設計接口時應當注意一下幾點：
1、一個類對一類的依賴應該建立在最小的接口之上。
2、建立單一接口，不要建立龐大臃腫的接口。
3、儘量細化接口，接口中的方法儘量少（不是越少越好，一定要適度）。
優點： 接口隔離原則符合我們常說的高內聚、低耦合的設計思想，從而使得類具有很好的可讀 性、可擴展性和可維護性。
我們在設計接口的時候，要多花時間去思考，要考慮業務模 型，包括以後有可能發生變更的地方還要做一些預判。所以，對於抽象，對業務模型的 理解是非常重要的。
迪米特法則（Law of Demeter）
定義： 迪米特原則是指一個對象應該對其他對象保持最少的瞭解，又叫最少知道原則（Least Knowledge Principle），儘量降低類與類之間的耦合。迪米特原則主要強調只和朋友交流，不和陌生人說話。出現在成員變量、方法的輸入、輸 出參數中的類都可以稱之爲成員朋友類，而出現在方法體內部的類不屬於朋友類。
里氏替換原則（Liskov Substitution Principle）
定義： 里氏替換原則是指如果對每一個類型爲 T1 的 對象 o1,都有類型爲 T2 的對象 o2,使得以 T1 定義的所有程序 P 在所有的對象 o1 都替換 成 o2 時，程序 P 的行爲沒有發生變化，那麼類型 T2 是類型 T1 的子類型。
理解： 定義看上去還是比較抽象，我們重新理解一下，可以理解爲一個軟件實體如果適用一 個父類的話，那一定是適用於其子類，所有引用父類的地方必須能透明地使用其子類的對象，子類對象能夠替換父類對象，而程序邏輯不變。
根據這個理解，我們總結一下： 引申含義：子類可以擴展父類的功能，但不能改變父類原有的功能。
1、子類可以實現父類的抽象方法，但不能覆蓋父類的非抽象方法。
2、子類中可以增加自己特有的方法。
3、當子類的方法重載父類的方法時，方法的前置條件（即方法的輸入/入參）要比父類 方法的輸入參數更寬鬆。
4、當子類的方法實現父類的方法時（重寫/重載或實現抽象方法），方法的後置條件（即 方法的輸出/返回值）要比父類更嚴格或相等。
優點：
1、約束繼承氾濫，開閉原則的一種體現。
2、加強程序的健壯性，同時變更時也可以做到非常好的兼容性，提高程序的維護性、擴展性。降低需求變更時引入的風險。
合成複用原則（Composite/Aggregate Reuse Principle）
定義： 合成複用原則是指儘量使用對象 組合(has-a)/聚合(contanis-a)，而不是繼承關係達到軟件複用的目的。
優點： 可以使系統更加靈活，降低類與類之間的耦合度，一個類的變化對其他類造成的影響相對較少。
擴展知識： 繼承我們叫做白箱複用，相當於把所有的實現細節暴露給子類。組合/聚合也稱之爲黑箱複用，對類以外的對象是無法獲取到實現細節的。要根據具體的業務場景來做代碼設 計，其實也都需要遵循 OOP 模型。
設計原則總結
學習設計原則是學習設計模式的基礎。在實際開發過程中，千萬不能形成強迫症。碰到業務複雜的場景，我們需要隨機應變。並不是一定要求所有代碼都遵循設計原則，我們要考慮人力、時間、成本、質量，不是刻意追求完美，要在適當的場景遵循設計原則，體現的是一種平衡取捨，幫助我們設計出更加優雅的代碼結構。