面向對象設計七原則
- 單一職責原則
- 開閉原則
- 裏式替換原則
- 依賴倒轉原則
- 接口隔離原則
- 迪米特法則
- 合成複用原則
1 單一職責原則
-
單一職責原則是最簡單的面向對象設計原則，它用於控制類的粒度大小。
-
單一職責原則定義如下：
- 單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義爲：就一個類而言，應該只有一個引起它變化的原因。
-
單一職責原則告訴我們：一個類不能太“累”！在軟件系統中，一個類（大到模塊，小到方法）承擔的職責越多，它被複用的可能性就越小，而且一個類承擔的職責過多，就相當於將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發生改變則可將它們封裝在同一類中。
-
單一職責原則是實現高內聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發現類的不同職責並將其分離，而發現類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經驗。
2 開閉原則
-
開閉原則是面向對象的可複用設計的第一塊基石，它是最重要的面向對象設計原則。開閉原則由Bertrand Meyer於1988年提出，其定義如下：
-
開閉原則(Open-Closed Principle, OCP)：一個軟件實體應當對擴展開放，對修改關閉。
即軟件實體應儘量在不修改原有代碼的情況下進行擴展。 -
在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。
任何軟件都需要面臨一個很重要的問題，即它們的需求會隨時間的推移而發生變化。
當軟件系統需要面對新的需求時，我們應該儘量保證系統的設計框架是穩定的。如果一個軟件設計符合開閉原則，那麼可以非常方便地對系統進行擴展，而且在擴展時無須修改現有代碼，使得軟件系統在擁有適應性和靈活性的同時具備較好的穩定性和延續性。
隨着軟件規模越來越大，軟件壽命越來越長，軟件維護成本越來越高，設計滿足開閉原則的軟件系統也變得越來越重要。
- 爲了滿足開閉原則，需要對系統進行抽象化設計，抽象化是開閉原則的關鍵。
在Java、C#等編程語言中，可以爲系統定義一個相對穩定的抽象層，而將不同的實現行爲移至具體的實現層中完成。
在很多面向對象編程語言中都提供了接口、抽象類等機制，可以通過它們定義系統的抽象層，再通過具體類來進行擴展。如果需要修改系統的行爲，無須對抽象層進行任何改動，只需要增加新的具體類來實現新的業務功能即可，實現在不修改已有代碼的基礎上擴展系統的功能，達到開閉原則的要求。
3 裏式替換原則
-
里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士Barbara Liskov教授和卡內基·梅隆大學Jeannette Wing教授於1994年提出。其嚴格表述如下：如果對每一個類型爲S的對象o1，都有類型爲T的對象o2，使得以T定義的所有程序P在所有的對象o1代換o2時，程序P的行爲沒有變化，那麼類型S是類型T的子類型。這個定義比較拗口且難以理解，因此我們一般使用它的另一個通俗版定義：
-
里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類（父類）的地方必須能透明地使用其子類的對象。
-
里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序將不會產生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那麼它不一定能夠使用基類對象。
-
例如：我喜歡動物，那我一定喜歡狗，因爲狗是動物的子類；但是我喜歡狗，不能據此斷定我喜歡動物，因爲我並不喜歡老鼠，雖然它也是動物。
-
例如有兩個類，一個類爲BaseClass，另一個是SubClass類，並且SubClass類是BaseClass類的子類，那麼一個方法如果可以接受一個BaseClass類型的基類對象base的話，如：method1(base)，那麼它必然可以接受一個BaseClass類型的子類對象sub，method1(sub)能夠正常運行。反過來的代換不成立，如一個方法method2接受BaseClass類型的子類對象sub爲參數：method2(sub)，那麼一般而言不可以有method2(base)，除非是重載方法。
-
里氏代換原則是實現開閉原則的重要方式之一，由於使用基類對象的地方都可以使用子類對象，因此在程序中儘量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。
在使用里氏代換原則時需要注意如下幾個問題：
(1)子類的所有方法必須在父類中聲明，或子類必須實現父類中聲明的所有方法。根據里氏代換原則，爲了保證系統的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。
(2) 我們在運用里氏代換原則時，儘量把父類設計爲抽象類或者接口，讓子類繼承父類或實現父接口，並實現在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現。里氏代換原則是開閉原則的具體實現手段之一。
(3) Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現無關的、純語法意義上的檢查，但Java編譯器的檢查是有侷限的。
4 依賴倒轉原則
-
如果說開閉原則是面向對象設計的目標的話，那麼依賴倒轉原則就是面向對象設計的主要實現機制之一，它是系統抽象化的具體實現。依賴倒轉原則是Robert C. Martin在1996年爲“C++Reporter”所寫的專欄Engineering Notebook的第三篇，後來加入到他在2002年出版的經典著作“Agile Software Development, Principles, Patterns, and Practices”一書中。
-
依賴倒轉原則定義如下： 依賴倒轉原則(Dependency Inversion Principle, DIP)：抽象不應該依賴於細節，細節應當依賴於抽象。換言之，要針對接口編程，而不是針對實現編程。
-
依賴倒轉原則要求我們在程序代碼中傳遞參數時或在關聯關係中，儘量引用層次高的抽象層類，即使用接口和抽象類進行變量類型聲明、參數類型聲明、方法返回類型聲明，以及數據類型的轉換等，而不要用具體類來做這些事情。爲了確保該原則的應用，一個具體類應當只實現接口或抽象類中聲明過的方法，而不要給出多餘的方法，否則將無法調用到在子類中增加的新方法。
-
在引入抽象層後，系統將具有很好的靈活性，在程序中儘量使用抽象層進行編程，而將具體類寫在配置文件中，這樣一來，如果系統行爲發生變化，只需要對抽象層進行擴展，並修改配置文件，而無須修改原有系統的源代碼，在不修改的情況下來擴展系統的功能，滿足開閉原則的要求。
-
在實現依賴倒轉原則時，我們需要針對抽象層編程，而將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發生依賴關係時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分別是：構造注入，設值注入（Setter注入）和接口注入。構造注入是指通過構造函數來傳入具體類的對象，設值注入是指通過Setter方法來傳入具體類的對象，而接口注入是指通過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型，在運行時再傳入具體類型的對象，由子類對象來覆蓋父類對象。
5 接口隔離原則
- 接口隔離原則定義如下：
接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。
- 根據接口隔離原則，當一個接口太大時，我們需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。每一個接口應該承擔一種相對獨立的角色，不幹不該乾的事，該乾的事都要幹。這裏的“接口”往往有兩種不同的含義：一種是指一個類型所具有的方法特徵的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴格的定義和結構，比如Java語言中的interface。對於這兩種不同的含義，ISP的表達方式以及含義都有所不同：
(1) 當把“接口”理解成一個類型所提供的所有方法特徵的集合的時候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。可以把接口理解成角色，一個接口只能代表一個角色，每個角色都有它特定的一個接口，此時，這個原則可以叫做“角色隔離原則”。
(2) 如果把“接口”理解成狹義的特定語言的接口，那麼ISP表達的意思是指接口僅僅提供客戶端需要的行爲，客戶端不需要的行爲則隱藏起來，應當爲客戶端提供儘可能小的單獨的接口，而不要提供大的總接口。在面向對象編程語言中，實現一個接口就需要實現該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，爲了使接口的職責單一，需要將大接口中的方法根據其職責不同分別放在不同的小接口中，以確保每個接口使用起來都較爲方便，並都承擔某一單一角色。接口應該儘量細化，同時接口中的方法應該儘量少，每個接口中只包含一個客戶端（如子模塊或業務邏輯類）所需的方法即可，這種機制也稱爲“定製服務”，即爲不同的客戶端提供寬窄不同的接口。
- 在使用接口隔離原則時，我們需要注意控制接口的粒度，接口不能太小，如果太小會導致系統中接口氾濫，不利於維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含爲某一類用戶定製的方法即可，不應該強迫客戶依賴於那些它們不用的方法。
6 迪米特法則
- 迪米特法則來自於1987年美國東北大學(Northeastern University)一個名爲“Demeter”的研究項目。迪米特法則又稱爲最少知識原則(LeastKnowledge Principle, LKP)，其定義如下：
迪米特法則(Law of Demeter, LoD)：一個軟件實體應當儘可能少地與其他實體發生相互作用。
-
如果一個系統符合迪米特法則，那麼當其中某一個模塊發生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統的耦合度，使類與類之間保持鬆散的耦合關係。
-
迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對於一個對象，其朋友包括以下幾類：
(1) 當前對象本身(this)；
(2) 以參數形式傳入到當前對象方法中的對象；
(3) 當前對象的成員對象；
(4) 如果當前對象的成員對象是一個集合，那麼集合中的元素也都是朋友；
(5) 當前對象所創建的對象。
任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發生交互，不要與“陌生人”發生直接交互，這樣做可以降低系統的耦合度，一個對象的改變不會給太多其他對象帶來影響。
-
迪米特法則要求我們在設計系統時，應該儘量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那麼這兩個對象就不應當發生任何直接的相互作用，如果其中的一個對象需要調用另一個對象的某一個方法的話，可以通過第三者轉發這個調用。簡言之，就是通過引入一個合理的第三者來降低現有對象之間的耦合度。
-
在將迪米特法則運用到系統設計中時，要注意下面的幾點：在類的劃分上，應當儘量創建松耦合的類，類之間的耦合度越低，就越有利於複用，一個處在松耦合中的類一旦被修改，不會對關聯的類造成太大波及；在類的結構設計上，每一個類都應當儘量降低其成員變量和成員函數的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。
7 合成複用原則
- 合成複用原則又稱爲組合/聚合複用原則(Composition/Aggregate Reuse Principle, CARP)，其定義如下：
合成複用原則(Composite Reuse Principle, CRP)：儘量使用對象組合，而不是繼承來達到複用的目的。
-
合成複用原則就是在一個新的對象裏通過關聯關係（包括組合關係和聚合關係）來使用一些已有的對象，使之成爲新對象的一部分；新對象通過委派調用已有對象的方法達到複用功能的目的。簡言之：複用時要儘量使用組合/聚合關係（關聯關係），少用繼承。
在面向對象設計中，可以通過兩種方法在不同的環境中複用已有的設計和實現，即通過組合/聚合關係或通過繼承，但首先應該考慮使用組合/聚合，組合/聚合可以使系統更加靈活，降低類與類之間的耦合度，一個類的變化對其他類造成的影響相對較少；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助於對問題的理解，降低複雜度，而濫用繼承反而會增加系統構建和維護的難度以及系統的複雜度，因此需要慎重使用繼承複用。 -
通過繼承來進行復用的主要問題在於繼承複用會破壞系統的封裝性，因爲繼承會將基類的實現細節暴露給子類，由於基類的內部細節通常對子類來說是可見的，所以這種複用又稱“白箱”複用，如果基類發生改變，那麼子類的實現也不得不發生改變；從基類繼承而來的實現是靜態的，不可能在運行時發生改變，沒有足夠的靈活性；而且繼承只能在有限的環境中使用（如類沒有聲明爲不能被繼承）。
-
擴展
對於繼承的深入理解，大家可以參考《軟件架構設計》一書作者溫昱先生的文章——《見山只是山見水只是水——提升對繼承的認識》。
由於組合或聚合關係可以將已有的對象（也可稱爲成員對象）納入到新對象中，使之成爲新對象的一部分，因此新對象可以調用已有對象的功能，這樣做可以使得成員對象的內部實現細節對於新對象不可見，所以這種複用又稱爲“黑箱”複用，相對繼承關係而言，其耦合度相對較低，成員對象的變化對新對象的影響不大，可以在新對象中根據實際需要有選擇性地調用成員對象的操作；合成複用可以在運行時動態進行，新對象可以動態地引用與成員對象類型相同的其他對象。
一般而言，如果兩個類之間是“Has-A”的關係應使用組合或聚合，如果是“Is-A”關係可使用繼承。“Is-A"是嚴格的分類學意義上的定義，意思是一個類是另一個類的"一種”；而"Has-A"則不同，它表示某一個角色具有某一項責任。