文章目錄
開閉原則（Open-Closed Principle）
定義：
開閉原則（Open Closed Principle，OCP）由勃蘭特·梅耶（Bertrand Meyer）提出，他在 1988 年的著作《面向對象軟件構造》（Object Oriented Software Construction）中提出：軟件實體應當對擴展開放，對修改關閉（Software entities should be open for extension，but closed for modification），這就是開閉原則的經典定義。
這裏的軟件實體包括以下幾個部分：
1.項目中劃分出的模塊
2.類與接口
3.方法
開閉原則的含義是：
當應用的需求改變時，在不修改軟件實體的源代碼或者二進制代碼的前提下，可以擴展模塊的功能，使其滿足新的需求。
作用：
開閉原則是面向對象程序設計的終極目標，它使軟件實體擁有一定的適應性和靈活性的同時具備穩定性和延續性。具體來說，其作用如下:
1. 對軟件測試的影響
軟件遵守開閉原則的話，軟件測試時只需要對擴展的代碼進行測試就可以了，因爲原有的測試代碼仍然能夠正常運行。
2. 可以提高代碼的可複用性
粒度越小，被複用的可能性就越大；在面向對象的程序設計中，根據原子和抽象編程可以提高代碼的可複用性。
3. 可以提高軟件的可維護性
遵守開閉原則的軟件，其穩定性高和延續性強，從而易於擴展和維護。
實現方法:
可以通過“抽象約束、封裝變化”來實現開閉原則，即通過接口或者抽象類爲軟件實體定義一個相對穩定的抽象層，而將相同的可變因素封裝在相同的具體實現類中。
因爲抽象靈活性好，適應性廣，只要抽象的合理，可以基本保持軟件架構的穩定。而軟件中易變的細節可以從抽象派生來的實現類來進行擴展，當軟件需要發生變化時，只需要根據需求重新派生一個實現類來擴展就可以了。
里氏替換原則（Liskov Substitution Principle）
定義：
里氏替換原則（Liskov Substitution Principle，LSP）由麻省理工學院計算機科學實驗室的里斯科夫（Liskov）女士在 1987 年的“面向對象技術的高峯會議”（OOPSLA）上發表的一篇文章《數據抽象和層次》（Data Abstraction and Hierarchy）裏提出來的，她提出：繼承必須確保超類所擁有的性質在子類中仍然成立（Inheritance should ensure that any property proved about supertype objects also holds for subtype objects）。
里氏替換原則主要闡述了有關繼承的一些原則，也就是什麼時候應該使用繼承，什麼時候不應該使用繼承，以及其中蘊含的原理。里氏替換原是繼承複用的基礎，它反映了基類與子類之間的關係，是對開閉原則的補充，是對實現抽象化的具體步驟的規範。
作用：
1.里氏替換原則是實現開閉原則的重要方式之一。
2.它克服了繼承中重寫父類造成的可複用性變差的缺點。
3.它是動作正確性的保證。即類的擴展不會給已有的系統引入新的錯誤，降低了代碼出錯的可能性。
實現方法:
里氏替換原則通俗來講就是：子類可以擴展父類的功能，但不能改變父類原有的功能。也就是說：子類繼承父類時，除添加新的方法完成新增功能外，儘量不要重寫父類的方法。
如果通過重寫父類的方法來完成新的功能，這樣寫起來雖然簡單，但是整個繼承體系的可複用性會比較差，特別是運用多態比較頻繁時，程序運行出錯的概率會非常大。
如果程序違背了里氏替換原則，則繼承類的對象在基類出現的地方會出現運行錯誤。這時其修正方法是：取消原來的繼承關係，重新設計它們之間的關係。
關於里氏替換原則的例子，最有名的是“正方形不是長方形”。當然，生活中也有很多類似的例子，例如，企鵝、鴕鳥和幾維鳥從生物學的角度來劃分，它們屬於鳥類；但從類的繼承關係來看，由於它們不能繼承“鳥”會飛的功能，所以它們不能定義成“鳥”的子類。同樣，由於“氣球魚”不會游泳，所以不能定義成“魚”的子類；“玩具炮”炸不了敵人，所以不能定義成“炮”的子類等。
依賴倒置原則（Dependence Inversion Principle）
定義：
依賴倒置原則（Dependence Inversion Principle，DIP）是 Object Mentor 公司總裁羅伯特·馬丁（Robert C.Martin）於 1996 年在 C++ Report 上發表的文章。依賴倒置原則的原始定義爲：高層模塊不應該依賴低層模塊，兩者都應該依賴其抽象；抽象不應該依賴細節，細節應該依賴抽象（High level modules shouldnot depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details. Details should depend upon abstractions）。其核心思想是：要面向接口編程，不要面向實現編程。依賴倒置原則是實現開閉原則的重要途徑之一，它降低了客戶與實現模塊之間的耦合。
由於在軟件設計中，細節具有多變性，而抽象層則相對穩定，因此以抽象爲基礎搭建起來的架構要比以細節爲基礎搭建起來的架構要穩定得多。這裏的抽象指的是接口或者抽象類，而細節是指具體的實現類。
使用接口或者抽象類的目的是制定好規範和契約，而不去涉及任何具體的操作，把展現細節的任務交給它們的實現類去完成。
作用：
依賴倒置原則的主要作用如下:
1.依賴倒置原則可以降低類間的耦合性。
2.依賴倒置原則可以提高系統的穩定性。
3.依賴倒置原則可以減少並行開發引起的風險。
4.依賴倒置原則可以提高代碼的可讀性和可維護性。
大家要切記：以抽象爲基準比以細節爲基準搭建起來的架構要穩定得多，因此大家在拿 到需求之後，要面向接口編程，先頂層再細節來設計代碼結構。
實現方法:
依賴倒置原則的目的是通過要面向接口的編程來降低類間的耦合性，所以我們在實際編程中只要遵循以下4點，就能在項目中滿足這個規則。
1.每個類儘量提供接口或抽象類，或者兩者都具備。
2.變量的聲明類型儘量是接口或者是抽象類。
3.任何類都不應該從具體類派生。
4.使用繼承時儘量遵循里氏替換原則。
單一職責原則（Simple Responsibility Pinciple）
定義 ：
單一職責原則（Single Responsibility Principle，SRP）又稱單一功能原則，由羅伯特·C.馬丁（Robert C. Martin）於《敏捷軟件開發：原則、模式和實踐》一書中提出的。這裏的職責是指類變化的原因，單一職責原則規定一個類應該有且僅有一個引起它變化的原因，否則類應該被拆分（There should never be more than one reason for a class to change）。
該原則提出對象不應該承擔太多職責，如果一個對象承擔了太多的職責，至少存在以下兩個缺點：
1.一個職責的變化可能會削弱或者抑制這個類實現其他職責的能力；
2.當客戶端需要該對象的某一個職責時，不得不將其他不需要的職責全都包含進來，從而造成冗餘代碼或代碼的浪費。
優點：
單一職責原則的核心就是控制類的粒度大小、將對象解耦、提高其內聚性。如果遵循單一職責原則將有以下優點：
1.降低類的複雜度。一個類只負責一項職責，其邏輯肯定要比負責多項職責簡單得多。
2.提高類的可讀性。複雜性降低，自然其可讀性會提高。
3.提高系統的可維護性。可讀性提高，那自然更容易維護了。
4.變更引起的風險降低。變更是必然的，如果單一職責原則遵守得好，當修改一個功能時，可以顯著降低對其他功能的影響。
實現方法:
單一職責原則是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，再封裝到不同的類或模塊中。而發現類的多重職責需要設計人員具有較強的分析設計能力和相關重構經驗。
接口隔離原則（Interface Segregation Principle）
定義：
2002 年羅伯特·C.馬丁給“接口隔離原則”的定義是：客戶端不應該被迫依賴於它不使用的方法（Clients should not be forced to depend on methods they do not use）。該原則還有另外一個定義：一個類對另一個類的依賴應該建立在最小的接口上（The dependency of one class to another one should depend on the smallest possible interface）。要爲各個類建立它們需要的專用接口，而不要試圖去建立一個很龐大的接口供所有依賴它的類去調用。
接口隔離原則和單一職責都是爲了提高類的內聚性、降低它們之間的耦合性，體現了封裝的思想，但兩者是不同的：
1.單一職責原則注重的是職責，而接口隔離原則注重的是對接口依賴的隔離。
2.單一職責原則主要是約束類，它針對的是程序中的實現和細節；接口隔離原則主要約束接口，主要針對抽象和程序整體框架的構建。
優點：
接口隔離原則是爲了約束接口、降低類對接口的依賴性，遵循接口隔離原則有以下 5 個優點：
1.將臃腫龐大的接口分解爲多個粒度小的接口，可以預防外來變更的擴散，提高系統的靈活性和可維護性。
2.接口隔離提高了系統的內聚性，減少了對外交互，降低了系統的耦合性。
3.如果接口的粒度大小定義合理，能夠保證系統的穩定性；但是，如果定義過小，則會造成接口數量過多，使設計複雜化；如果定義太大靈活性降低，無法提供定製服務，給整體項目帶來無法預料的風險。
4.使用多個專門的接口還能夠體現對象的層次，因爲可以通過接口的繼承，實現對總接口的定義。
5.能減少項目工程中的代碼冗餘。過大的大接口裏面通常放置許多不用的方法，當實現這個接口的時候，被迫設計冗餘的代碼。
實現方法:
在具體應用接口隔離原則時，應該根據以下幾個規則來衡量：
1.接口儘量小，但是要有限度。一個接口只服務於一個子模塊或業務邏輯。
2.爲依賴接口的類定製服務。只提供調用者需要的方法，屏蔽不需要的方法。
3.瞭解環境，拒絕盲從。每個項目或產品都有選定的環境因素，環境不同，接口拆分的標準就不同深入瞭解業務邏輯。
4.提高內聚，減少對外交互。使接口用最少的方法去完成最多的事情。
迪米特法則（Law of Demeter）
定義：
迪米特法則（Law of Demeter，LoD）又叫作最少知識原則（Least Knowledge Principle，LKP)，產生於 1987 年美國東北大學（Northeastern University）的一個名爲迪米特（Demeter）的研究項目，由伊恩·荷蘭（Ian Holland）提出，被 UML 創始者之一的布奇（Booch）普及，後來又因爲在經典著作《程序員修煉之道》（The Pragmatic Programmer）提及而廣爲人知。
迪米特法則的定義是：只與你的直接朋友交談，不跟“陌生人”說話（Talk only to your immediate friends and not to strangers）。其含義是：如果兩個軟件實體無須直接通信，那麼就不應當發生直接的相互調用，可以通過第三方轉發該調用。其目的是降低類之間的耦合度，提高模塊的相對獨立性。
迪米特法則中的“朋友”是指：當前對象本身、當前對象的成員對象、當前對象所創建的對象、當前對象的方法參數等，這些對象同當前對象存在關聯、聚合或組合關係，可以直接訪問這些對象的方法。
優點：
迪米特法則要求限制軟件實體之間通信的寬度和深度，正確使用迪米特法則將有以下兩個優點：
1.降低了類之間的耦合度，提高了模塊的相對獨立性。
2.由於親合度降低，從而提高了類的可複用率和系統的擴展性。
但是，過度使用迪米特法則會使系統產生大量的中介類，從而增加系統的複雜性，使模塊之間的通信效率降低。所以，在釆用迪米特法則時需要反覆權衡，確保高內聚和低耦合的同時，保證系統的結構清晰。
實現方法:
從迪米特法則的定義和特點可知，它強調以下兩點：
1.從依賴者的角度來說，只依賴應該依賴的對象。
2.從被依賴者的角度說，只暴露應該暴露的方法。
所以，在運用迪米特法則時要注意以下 6 點：
1.在類的劃分上，應該創建弱耦合的類。類與類之間的耦合越弱，就越有利於實現可複用的目標。
2.在類的結構設計上，儘量降低類成員的訪問權限。
3.在類的設計上，優先考慮將一個類設置成不變類。
4.在對其他類的引用上，將引用其他對象的次數降到最低。
5.不暴露類的屬性成員，而應該提供相應的訪問器（set 和 get 方法）。
6.謹慎使用序列化（Serializable）功能。
合成複用原則（Composite/Aggregate Reuse Principle）
定義：
合成複用原則（Composite Reuse Principle，CRP）又叫組合/聚合複用原則（Composition/Aggregate Reuse Principle，CARP）。它要求在軟件複用時，要儘量先使用組合或者聚合等關聯關係來實現，其次才考慮使用繼承關係來實現。
如果要使用繼承關係，則必須嚴格遵循里氏替換原則。合成複用原則同里氏替換原則相輔相成的，兩者都是開閉原則的具體實現規範。
合成複用原則的重要性：
~通常類的複用分爲繼承複用和合成複用兩種，繼承複用雖然有簡單和易實現的優點，但它也存在以下缺點：
1.繼承複用破壞了類的封裝性。因爲繼承會將父類的實現細節暴露給子類，父類對子類是透明的，所以這種複用又稱爲“白箱”複用。
2.子類與父類的耦合度高。父類的實現的任何改變都會導致子類的實現發生變化，這不利於類的擴展與維護。
3.它限制了複用的靈活性。從父類繼承而來的實現是靜態的，在編譯時已經定義，所以在運行時不可能發生變化。
~採用組合或聚合複用時，可以將已有對象納入新對象中，使之成爲新對象的一部分，新對象可以調用已有對象的功能，它有以下優點：
1.它維持了類的封裝性。因爲成分對象的內部細節是新對象看不見的，所以這種複用又稱爲“黑箱”複用。
2.新舊類之間的耦合度低。這種複用所需的依賴較少，新對象存取成分對象的唯一方法是通過成分對象的接口。
3.複用的靈活性高。這種複用可以在運行時動態進行，新對象可以動態地引用與成分對象類型相同的對象。
實現方法:
合成複用原則是通過將已有的對象納入新對象中，作爲新對象的成員對象來實現的，新對象可以調用已有對象的功能，從而達到複用。
擴展知識： 繼承我們叫做白箱複用，相當於把所有的實現細節暴露給子類。組合/聚合也稱之爲黑箱複用，對類以外的對象是無法獲取到實現細節的。要根據具體的業務場景來做代碼設 計，其實也都需要遵循OOP 模型。
設計原則總結
學習設計原則是學習設計模式的基礎。在實際開發過程中，千萬不能形成強迫症。碰到業務複雜的場景，我們需要隨機應變。並不是一定要求所有代碼都遵循設計原則，我們要考慮人力、時間、成本、質量，不是刻意追求完美，要在適當的場景遵循設計原則，體現的是一種平衡取捨，幫助我們設計出更加優雅的代碼結構。
此篇爲設計模式開篇