作者 薛之謙qxl? 轉(zhuǎn)載請注明出處

我的知乎原文：https://zhuanlan.zhihu.com/p/126674963

內(nèi)容簡介

對于面向?qū)ο筌浖到y(tǒng)的設計而言，在支持可維護性的同時，提高系統(tǒng)的可復用性是一個至關重要的問題，如何同時提高一個軟件系統(tǒng)的可維護性和可復用性是面向?qū)ο笤O計需要解決的核心問題之一。在面向?qū)ο笤O計中，可維護性的復用是以設計原則為基礎的。每一個原則都蘊含一些面向?qū)ο笤O計的思想，可以從不同的角度提升一個軟件結構的設計水平。

面向?qū)ο笤O計原則為支持可維護性復用而誕生，這些原則蘊含在很多設計模式中，它們是從許多設計方案中總結出的指導性原則。面向?qū)ο笤O計原則也是我們用于評價一個設計模式的使用效果的重要指標之一，在設計模式的學習中，大家經(jīng)常會看到諸如“XXX模式符合XXX原則”、“XXX模式違反了XXX原則”這樣的語句。

7種常用的面向?qū)ο笤O計原則

面向?qū)ο笤O計原則之單一職責原則：

單一職責原則是最簡單的面向?qū)ο笤O計原則，它用于控制類的粒度大小。單一職責原則定義如下：

單一職責原則(Single Responsibility Principle, SRP)：一個類只負責一個功能領域中的相應職責，或者可以定義為：就一個類而言，應該只有一個引起它變化的原因。

單一職責原則告訴我們：一個類不能太“累”！在軟件系統(tǒng)中，一個類（大到模塊，小到方法）承擔的職責越多，它被復用的可能性就越小，而且一個類承擔的職責過多，就相當于將這些職責耦合在一起，當其中一個職責變化時，可能會影響其他職責的運作，因此要將這些職責進行分離，將不同的職責封裝在不同的類中，即將不同的變化原因封裝在不同的類中，如果多個職責總是同時發(fā)生改變則可將它們封裝在同一類中。

單一職責原則是實現(xiàn)高內(nèi)聚、低耦合的指導方針，它是最簡單但又最難運用的原則，需要設計人員發(fā)現(xiàn)類的不同職責并將其分離，而發(fā)現(xiàn)類的多重職責需要設計人員具有較強的分析設計能力和相關實踐經(jīng)驗。

下面通過一個簡單實例來進一步分析單一職責原則：

Sunny軟件公司開發(fā)人員針對某CRM（Customer Relationship Management，客戶關系管理）系統(tǒng)中客戶信息圖形統(tǒng)計模塊提出了如圖1所示初始設計方案：

圖1 初始設計方案結構圖

在圖1中，CustomerDataChart類中的方法說明如下：getConnection()方法用于連接數(shù)據(jù)庫，findCustomers()用于查詢所有的客戶信息，createChart()用于創(chuàng)建圖表，displayChart()用于顯示圖表。

現(xiàn)使用單一職責原則對其進行重構。

在圖1中，CustomerDataChart類承擔了太多的職責，既包含與數(shù)據(jù)庫相關的方法，又包含與圖表生成和顯示相關的方法。如果在其他類中也需要連接數(shù)據(jù)庫或者使用findCustomers()方法查詢客戶信息，則難以實現(xiàn)代碼的重用。無論是修改數(shù)據(jù)庫連接方式還是修改圖表顯示方式都需要修改該類，它不止一個引起它變化的原因，違背了單一職責原則。因此需要對該類進行拆分，使其滿足單一職責原則，類CustomerDataChart可拆分為如下三個類：

(1) DBUtil：負責連接數(shù)據(jù)庫，包含數(shù)據(jù)庫連接方法getConnection()；

(2) CustomerDAO：負責操作數(shù)據(jù)庫中的Customer表，包含對Customer表的增刪改查等方法，如findCustomers()；

(3) CustomerDataChart：負責圖表的生成和顯示，包含方法createChart()和displayChart()。

使用單一職責原則重構后的結構如圖2所示：

圖2 重構后的結構圖

面向?qū)ο笤O計原則之開閉原則：

開閉原則是面向?qū)ο蟮目蓮陀迷O計的第一塊基石，它是最重要的面向?qū)ο笤O計原則。開閉原則由Bertrand Meyer于1988年提出，其定義如下：

開閉原則(Open-Closed Principle, OCP)：一個軟件實體應當對擴展開放，對修改關閉。即軟件實體應盡量在不修改原有代碼的情況下進行擴展。

在開閉原則的定義中，軟件實體可以指一個軟件模塊、一個由多個類組成的局部結構或一個獨立的類。

任何軟件都需要面臨一個很重要的問題，即它們的需求會隨時間的推移而發(fā)生變化。當軟件系統(tǒng)需要面對新的需求時，我們應該盡量保證系統(tǒng)的設計框架是穩(wěn)定的。如果一個軟件設計符合開閉原則，那么可以非常方便地對系統(tǒng)進行擴展，而且在擴展時無須修改現(xiàn)有代碼，使得軟件系統(tǒng)在擁有適應性和靈活性的同時具備較好的穩(wěn)定性和延續(xù)性。隨著軟件規(guī)模越來越大，軟件壽命越來越長，軟件維護成本越來越高，設計滿足開閉原則的軟件系統(tǒng)也變得越來越重要。

為了滿足開閉原則，需要對系統(tǒng)進行抽象化設計，抽象化是開閉原則的關鍵。在Java、C#等編程語言中，可以為系統(tǒng)定義一個相對穩(wěn)定的抽象層，而將不同的實現(xiàn)行為移至具體的實現(xiàn)層中完成。在很多面向?qū)ο缶幊陶Z言中都提供了接口、抽象類等機制，可以通過它們定義系統(tǒng)的抽象層，再通過具體類來進行擴展。如果需要修改系統(tǒng)的行為，無須對抽象層進行任何改動，只需要增加新的具體類來實現(xiàn)新的業(yè)務功能即可，實現(xiàn)在不修改已有代碼的基礎上擴展系統(tǒng)的功能，達到開閉原則的要求。

Sunny軟件公司開發(fā)的CRM系統(tǒng)可以顯示各種類型的圖表，如餅狀圖和柱狀圖等，為了支持多種圖表顯示方式，原始設計方案如圖3所示：

圖3 初始設計方案結構圖

在ChartDisplay類的display()方法中存在如下代碼片段：

在該代碼中，如果需要增加一個新的圖表類，如折線圖LineChart，則需要修改ChartDisplay類的display()方法的源代碼，增加新的判斷邏輯，違反了開閉原則。

現(xiàn)對該系統(tǒng)進行重構，使之符合開閉原則。

在本實例中，由于在ChartDisplay類的display()方法中針對每一個圖表類編程，因此增加新的圖表類不得不修改源代碼。可以通過抽象化的方式對系統(tǒng)進行重構，使之增加新的圖表類時無須修改源代碼，滿足開閉原則。具體做法如下：

(1) 增加一個抽象圖表類AbstractChart，將各種具體圖表類作為其子類；

(2) ChartDisplay類針對抽象圖表類進行編程，由客戶端來決定使用哪種具體圖表。

重構后結構如圖4所示：

圖4 重構后的結構圖

在圖4中，我們引入了抽象圖表類AbstractChart，且ChartDisplay針對抽象圖表類進行編程，并通過setChart()方法由客戶端來設置實例化的具體圖表對象，在ChartDisplay的display()方法中調(diào)用chart對象的display()方法顯示圖表。如果需要增加一種新的圖表，如折線圖LineChart，只需要將LineChart也作為AbstractChart的子類，在客戶端向ChartDisplay中注入一個LineChart對象即可，無須修改現(xiàn)有類庫的源代碼。

注意：因為xml和properties等格式的配置文件是純文本文件，可以直接通過VI編輯器或記事本進行編輯，且無須編譯，因此在軟件開發(fā)中，一般不把對配置文件的修改認為是對系統(tǒng)源代碼的修改。如果一個系統(tǒng)在擴展時只涉及到修改配置文件，而原有的Java代碼或C#代碼沒有做任何修改，該系統(tǒng)即可認為是一個符合開閉原則的系統(tǒng)。

面向?qū)ο笤O計原則之里氏代換原則：

里氏代換原則由2008年圖靈獎得主、美國第一位計算機科學女博士Barbara Liskov教授和卡內(nèi)基·梅隆大學Jeannette Wing教授于1994年提出。其嚴格表述如下：如果對每一個類型為S的對象o1，都有類型為T的對象o2，使得以T定義的所有程序P在所有的對象o1代換o2時，程序P的行為沒有變化，那么類型S是類型T的子類型。這個定義比較拗口且難以理解，因此我們一般使用它的另一個通俗版定義：

里氏代換原則(Liskov Substitution Principle, LSP)：所有引用基類（父類）的地方必須能透明地使用其子類的對象。

里氏代換原則告訴我們，在軟件中將一個基類對象替換成它的子類對象，程序?qū)⒉粫a(chǎn)生任何錯誤和異常，反過來則不成立，如果一個軟件實體使用的是一個子類對象的話，那么它不一定能夠使用基類對象。例如：我喜歡動物，那我一定喜歡狗，因為狗是動物的子類；但是我喜歡狗，不能據(jù)此斷定我喜歡動物，因為我并不喜歡老鼠，雖然它也是動物。

例如有兩個類，一個類為BaseClass，另一個是SubClass類，并且SubClass類是BaseClass類的子類，那么一個方法如果可以接受一個BaseClass類型的基類對象base的話，如：method1(base)，那么它必然可以接受一個BaseClass類型的子類對象sub，method1(sub)能夠正常運行。反過來的代換不成立，如一個方法method2接受BaseClass類型的子類對象sub為參數(shù)：method2(sub)，那么一般而言不可以有method2(base)，除非是重載方法。

里氏代換原則是實現(xiàn)開閉原則的重要方式之一，由于使用基類對象的地方都可以使用子類對象，因此在程序中盡量使用基類類型來對對象進行定義，而在運行時再確定其子類類型，用子類對象來替換父類對象。

在使用里氏代換原則時需要注意如下幾個問題：

(1)子類的所有方法必須在父類中聲明，或子類必須實現(xiàn)父類中聲明的所有方法。根據(jù)里氏代換原則，為了保證系統(tǒng)的擴展性，在程序中通常使用父類來進行定義，如果一個方法只存在子類中，在父類中不提供相應的聲明，則無法在以父類定義的對象中使用該方法。

(2) 我們在運用里氏代換原則時，盡量把父類設計為抽象類或者接口，讓子類繼承父類或?qū)崿F(xiàn)父接口，并實現(xiàn)在父類中聲明的方法，運行時，子類實例替換父類實例，我們可以很方便地擴展系統(tǒng)的功能，同時無須修改原有子類的代碼，增加新的功能可以通過增加一個新的子類來實現(xiàn)。里氏代換原則是開閉原則的具體實現(xiàn)手段之一。

(3) Java語言中，在編譯階段，Java編譯器會檢查一個程序是否符合里氏代換原則，這是一個與實現(xiàn)無關的、純語法意義上的檢查，但Java編譯器的檢查是有局限的。

在Sunny軟件公司開發(fā)的CRM系統(tǒng)中，客戶(Customer)可以分為VIP客戶(VIPCustomer)和普通客戶(CommonCustomer)兩類，系統(tǒng)需要提供一個發(fā)送Email的功能，原始設計方案如圖5所示：

圖5 原始結構圖

在對系統(tǒng)進行進一步分析后發(fā)現(xiàn)，無論是普通客戶還是VIP客戶，發(fā)送郵件的過程都是相同的，也就是說兩個send()方法中的代碼重復，而且在本系統(tǒng)中還將增加新類型的客戶。為了讓系統(tǒng)具有更好的擴展性，同時減少代碼重復，使用里氏代換原則對其進行重構。

在本實例中，可以考慮增加一個新的抽象客戶類Customer，而將CommonCustomer和VIPCustomer類作為其子類，郵件發(fā)送類EmailSender類針對抽象客戶類Customer編程，根據(jù)里氏代換原則，能夠接受基類對象的地方必然能夠接受子類對象，因此將EmailSender中的send()方法的參數(shù)類型改為Customer，如果需要增加新類型的客戶，只需將其作為Customer類的子類即可。重構后的結構如圖6所示：

圖6 重構后的結構圖

里氏代換原則是實現(xiàn)開閉原則的重要方式之一。在本實例中，在傳遞參數(shù)時使用基類對象，除此以外，在定義成員變量、定義局部變量、確定方法返回類型時都可使用里氏代換原則。針對基類編程，在程序運行時再確定具體子類。

擴展知識：

里氏代換原則以Barbara Liskov（芭芭拉·利斯科夫）教授的姓氏命名。芭芭拉·利斯科夫：美國計算機科學家，2008年圖靈獎得主，2004年約翰·馮諾依曼獎得主，美國工程院院士，美國藝術與科學院院士，美國計算機協(xié)會會士，麻省理工學院電子電氣與計算機科學系教授，美國第一位計算機科學女博士。

面向?qū)ο笤O計原則之依賴倒轉(zhuǎn)原則：

如果說開閉原則是面向?qū)ο笤O計的目標的話，那么依賴倒轉(zhuǎn)原則就是面向?qū)ο笤O計的主要實現(xiàn)機制之一，它是系統(tǒng)抽象化的具體實現(xiàn)。依賴倒轉(zhuǎn)原則是Robert C. Martin在1996年為“C++Reporter”所寫的專欄Engineering Notebook的第三篇，后來加入到他在2002年出版的經(jīng)典著作“Agile Software Development, Principles, Patterns, and Practices”一書中。依賴倒轉(zhuǎn)原則定義如下：

依賴倒轉(zhuǎn)原則(Dependency Inversion Principle, DIP)：抽象不應該依賴于細節(jié)，細節(jié)應當依賴于抽象。換言之，要針對接口編程，而不是針對實現(xiàn)編程。

依賴倒轉(zhuǎn)原則要求我們在程序代碼中傳遞參數(shù)時或在關聯(lián)關系中，盡量引用層次高的抽象層類，即使用接口和抽象類進行變量類型聲明、參數(shù)類型聲明、方法返回類型聲明，以及數(shù)據(jù)類型的轉(zhuǎn)換等，而不要用具體類來做這些事情。為了確保該原則的應用，一個具體類應當只實現(xiàn)接口或抽象類中聲明過的方法，而不要給出多余的方法，否則將無法調(diào)用到在子類中增加的新方法。

在引入抽象層后，系統(tǒng)將具有很好的靈活性，在程序中盡量使用抽象層進行編程，而將具體類寫在配置文件中，這樣一來，如果系統(tǒng)行為發(fā)生變化，只需要對抽象層進行擴展，并修改配置文件，而無須修改原有系統(tǒng)的源代碼，在不修改的情況下來擴展系統(tǒng)的功能，滿足開閉原則的要求。

在實現(xiàn)依賴倒轉(zhuǎn)原則時，我們需要針對抽象層編程，而將具體類的對象通過依賴注入(DependencyInjection, DI)的方式注入到其他對象中，依賴注入是指當一個對象要與其他對象發(fā)生依賴關系時，通過抽象來注入所依賴的對象。常用的注入方式有三種，分別是：構造注入，設值注入（Setter注入）和接口注入。構造注入是指通過構造函數(shù)來傳入具體類的對象，設值注入是指通過Setter方法來傳入具體類的對象，而接口注入是指通過在接口中聲明的業(yè)務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型，在運行時再傳入具體類型的對象，由子類對象來覆蓋父類對象。

下面通過一個簡單實例來加深對依賴倒轉(zhuǎn)原則的理解：

Sunny軟件公司開發(fā)人員在開發(fā)某CRM系統(tǒng)時發(fā)現(xiàn)：該系統(tǒng)經(jīng)常需要將存儲在TXT或Excel文件中的客戶信息轉(zhuǎn)存到數(shù)據(jù)庫中，因此需要進行數(shù)據(jù)格式轉(zhuǎn)換。在客戶數(shù)據(jù)操作類中將調(diào)用數(shù)據(jù)格式轉(zhuǎn)換類的方法實現(xiàn)格式轉(zhuǎn)換和數(shù)據(jù)庫插入操作，初始設計方案結構如圖7所示：

圖7 初始設計方案結構圖

在編碼實現(xiàn)圖7所示結構時，Sunny軟件公司開發(fā)人員發(fā)現(xiàn)該設計方案存在一個非常嚴重的問題，由于每次轉(zhuǎn)換數(shù)據(jù)時數(shù)據(jù)來源不一定相同，因此需要更換數(shù)據(jù)轉(zhuǎn)換類，如有時候需要將TXTDataConvertor改為ExcelDataConvertor，此時，需要修改CustomerDAO的源代碼，而且在引入并使用新的數(shù)據(jù)轉(zhuǎn)換類時也不得不修改CustomerDAO的源代碼，系統(tǒng)擴展性較差，違反了開閉原則，現(xiàn)需要對該方案進行重構。

在本實例中，由于CustomerDAO針對具體數(shù)據(jù)轉(zhuǎn)換類編程，因此在增加新的數(shù)據(jù)轉(zhuǎn)換類或者更換數(shù)據(jù)轉(zhuǎn)換類時都不得不修改CustomerDAO的源代碼。我們可以通過引入抽象數(shù)據(jù)轉(zhuǎn)換類解決該問題，在引入抽象數(shù)據(jù)轉(zhuǎn)換類DataConvertor之后，CustomerDAO針對抽象類DataConvertor編程，而將具體數(shù)據(jù)轉(zhuǎn)換類名存儲在配置文件中，符合依賴倒轉(zhuǎn)原則。根據(jù)里氏代換原則，程序運行時，具體數(shù)據(jù)轉(zhuǎn)換類對象將替換DataConvertor類型的對象，程序不會出現(xiàn)任何問題。更換具體數(shù)據(jù)轉(zhuǎn)換類時無須修改源代碼，只需要修改配置文件；如果需要增加新的具體數(shù)據(jù)轉(zhuǎn)換類，只要將新增數(shù)據(jù)轉(zhuǎn)換類作為DataConvertor的子類并修改配置文件即可，原有代碼無須做任何修改，滿足開閉原則。重構后的結構如圖8所示：

圖8 重構后的結構圖

在上述重構過程中，我們使用了開閉原則、里氏代換原則和依賴倒轉(zhuǎn)原則，在大多數(shù)情況下，這三個設計原則會同時出現(xiàn)，開閉原則是目標，里氏代換原則是基礎，依賴倒轉(zhuǎn)原則是手段，它們相輔相成，相互補充，目標一致，只是分析問題時所站角度不同而已。

面向?qū)ο笤O計原則之接口隔離原則：

接口隔離原則定義如下：

接口隔離原則(Interface Segregation Principle, ISP)：使用多個專門的接口，而不使用單一的總接口，即客戶端不應該依賴那些它不需要的接口。

根據(jù)接口隔離原則，當一個接口太大時，我們需要將它分割成一些更細小的接口，使用該接口的客戶端僅需知道與之相關的方法即可。每一個接口應該承擔一種相對獨立的角色，不干不該干的事，該干的事都要干。這里的“接口”往往有兩種不同的含義：一種是指一個類型所具有的方法特征的集合，僅僅是一種邏輯上的抽象；另外一種是指某種語言具體的“接口”定義，有嚴格的定義和結構，比如Java語言中的interface。對于這兩種不同的含義，ISP的表達方式以及含義都有所不同：

(1) 當把“接口”理解成一個類型所提供的所有方法特征的集合的時候，這就是一種邏輯上的概念，接口的劃分將直接帶來類型的劃分。可以把接口理解成角色，一個接口只能代表一個角色，每個角色都有它特定的一個接口，此時，這個原則可以叫做“角色隔離原則”。

(2) 如果把“接口”理解成狹義的特定語言的接口，那么ISP表達的意思是指接口僅僅提供客戶端需要的行為，客戶端不需要的行為則隱藏起來，應當為客戶端提供盡可能小的單獨的接口，而不要提供大的總接口。在面向?qū)ο缶幊陶Z言中，實現(xiàn)一個接口就需要實現(xiàn)該接口中定義的所有方法，因此大的總接口使用起來不一定很方便，為了使接口的職責單一，需要將大接口中的方法根據(jù)其職責不同分別放在不同的小接口中，以確保每個接口使用起來都較為方便，并都承擔某一單一角色。接口應該盡量細化，同時接口中的方法應該盡量少，每個接口中只包含一個客戶端（如子模塊或業(yè)務邏輯類）所需的方法即可，這種機制也稱為“定制服務”，即為不同的客戶端提供寬窄不同的接口。

下面通過一個簡單實例來加深對接口隔離原則的理解：

Sunny軟件公司開發(fā)人員針對某CRM系統(tǒng)的客戶數(shù)據(jù)顯示模塊設計了如圖9所示接口，其中方法dataRead()用于從文件中讀取數(shù)據(jù)，方法transformToXML()用于將數(shù)據(jù)轉(zhuǎn)換成XML格式，方法createChart()用于創(chuàng)建圖表，方法displayChart()用于顯示圖表，方法createReport()用于創(chuàng)建文字報表，方法displayReport()用于顯示文字報表。

圖9 初始設計方案結構圖

在實際使用過程中發(fā)現(xiàn)該接口很不靈活，例如如果一個具體的數(shù)據(jù)顯示類無須進行數(shù)據(jù)轉(zhuǎn)換（源文件本身就是XML格式），但由于實現(xiàn)了該接口，將不得不實現(xiàn)其中聲明的transformToXML()方法（至少需要提供一個空實現(xiàn)）；如果需要創(chuàng)建和顯示圖表，除了需實現(xiàn)與圖表相關的方法外，還需要實現(xiàn)創(chuàng)建和顯示文字報表的方法，否則程序編譯時將報錯。

現(xiàn)使用接口隔離原則對其進行重構。

在圖9中，由于在接口CustomerDataDisplay中定義了太多方法，即該接口承擔了太多職責，一方面導致該接口的實現(xiàn)類很龐大，在不同的實現(xiàn)類中都不得不實現(xiàn)接口中定義的所有方法，靈活性較差，如果出現(xiàn)大量的空方法，將導致系統(tǒng)中產(chǎn)生大量的無用代碼，影響代碼質(zhì)量；另一方面由于客戶端針對大接口編程，將在一定程序上破壞程序的封裝性，客戶端看到了不應該看到的方法，沒有為客戶端定制接口。因此需要將該接口按照接口隔離原則和單一職責原則進行重構，將其中的一些方法封裝在不同的小接口中，確保每一個接口使用起來都較為方便，并都承擔某一單一角色，每個接口中只包含一個客戶端（如模塊或類）所需的方法即可。

通過使用接口隔離原則，本實例重構后的結構如圖10所示：

圖10 重構后的結構圖

在使用接口隔離原則時，我們需要注意控制接口的粒度，接口不能太小，如果太小會導致系統(tǒng)中接口泛濫，不利于維護；接口也不能太大，太大的接口將違背接口隔離原則，靈活性較差，使用起來很不方便。一般而言，接口中僅包含為某一類用戶定制的方法即可，不應該強迫客戶依賴于那些它們不用的方法。

擴展知識：

在《敏捷軟件開發(fā)——原則、模式與實踐》一書中，RobertC. Martin從解決“接口污染”的角度對接口隔離原則進行了詳細的介紹，大家可以參閱該書第12章——接口隔離原則(ISP)進行深入的學習。

面向?qū)ο笤O計原則之合成復用原則：

合成復用原則又稱為組合/聚合復用原則(Composition/Aggregate Reuse Principle, CARP)，其定義如下：

合成復用原則(Composite Reuse Principle, CRP)：盡量使用對象組合，而不是繼承來達到復用的目的。

合成復用原則就是在一個新的對象里通過關聯(lián)關系（包括組合關系和聚合關系）來使用一些已有的對象，使之成為新對象的一部分；新對象通過委派調(diào)用已有對象的方法達到復用功能的目的。簡言之：復用時要盡量使用組合/聚合關系（關聯(lián)關系），少用繼承。

在面向?qū)ο笤O計中，可以通過兩種方法在不同的環(huán)境中復用已有的設計和實現(xiàn)，即通過組合/聚合關系或通過繼承，但首先應該考慮使用組合/聚合，組合/聚合可以使系統(tǒng)更加靈活，降低類與類之間的耦合度，一個類的變化對其他類造成的影響相對較少；其次才考慮繼承，在使用繼承時，需要嚴格遵循里氏代換原則，有效使用繼承會有助于對問題的理解，降低復雜度，而濫用繼承反而會增加系統(tǒng)構建和維護的難度以及系統(tǒng)的復雜度，因此需要慎重使用繼承復用。

通過繼承來進行復用的主要問題在于繼承復用會破壞系統(tǒng)的封裝性，因為繼承會將基類的實現(xiàn)細節(jié)暴露給子類，由于基類的內(nèi)部細節(jié)通常對子類來說是可見的，所以這種復用又稱“白箱”復用，如果基類發(fā)生改變，那么子類的實現(xiàn)也不得不發(fā)生改變；從基類繼承而來的實現(xiàn)是靜態(tài)的，不可能在運行時發(fā)生改變，沒有足夠的靈活性；而且繼承只能在有限的環(huán)境中使用（如類沒有聲明為不能被繼承）。

擴展知識：

對于繼承的深入理解，大家可以參考《軟件架構設計》一書作者溫昱先生的文章——《見山只是山見水只是水——提升對繼承的認識》。

由于組合或聚合關系可以將已有的對象（也可稱為成員對象）納入到新對象中，使之成為新對象的一部分，因此新對象可以調(diào)用已有對象的功能，這樣做可以使得成員對象的內(nèi)部實現(xiàn)細節(jié)對于新對象不可見，所以這種復用又稱為“黑箱”復用，相對繼承關系而言，其耦合度相對較低，成員對象的變化對新對象的影響不大，可以在新對象中根據(jù)實際需要有選擇性地調(diào)用成員對象的操作；合成復用可以在運行時動態(tài)進行，新對象可以動態(tài)地引用與成員對象類型相同的其他對象。

一般而言，如果兩個類之間是“Has-A”的關系應使用組合或聚合，如果是“Is-A”關系可使用繼承。"Is-A"是嚴格的分類學意義上的定義，意思是一個類是另一個類的"一種"；而"Has-A"則不同，它表示某一個角色具有某一項責任。

下面通過一個簡單實例來加深對合成復用原則的理解：

Sunny軟件公司開發(fā)人員在初期的CRM系統(tǒng)設計中，考慮到客戶數(shù)量不多，系統(tǒng)采用MySQL作為數(shù)據(jù)庫，與數(shù)據(jù)庫操作有關的類如CustomerDAO類等都需要連接數(shù)據(jù)庫，連接數(shù)據(jù)庫的方法getConnection()封裝在DBUtil類中，由于需要重用DBUtil類的getConnection()方法，設計人員將CustomerDAO作為DBUtil類的子類，初始設計方案結構如圖11所示：

圖11 初始設計方案結構圖

隨著客戶數(shù)量的增加，系統(tǒng)決定升級為Oracle數(shù)據(jù)庫，因此需要增加一個新的OracleDBUtil類來連接Oracle數(shù)據(jù)庫，由于在初始設計方案中CustomerDAO和DBUtil之間是繼承關系，因此在更換數(shù)據(jù)庫連接方式時需要修改CustomerDAO類的源代碼，將CustomerDAO作為OracleDBUtil的子類，這將違反開閉原則。【當然也可以修改DBUtil類的源代碼，同樣會違反開閉原則?！?/p>

現(xiàn)使用合成復用原則對其進行重構。

根據(jù)合成復用原則，我們在實現(xiàn)復用時應該多用關聯(lián)，少用繼承。因此在本實例中我們可以使用關聯(lián)復用來取代繼承復用，重構后的結構如圖12所示：

圖12 重構后的結構圖

在圖12中，CustomerDAO和DBUtil之間的關系由繼承關系變?yōu)殛P聯(lián)關系，采用依賴注入的方式將DBUtil對象注入到CustomerDAO中，可以使用構造注入，也可以使用Setter注入。如果需要對DBUtil的功能進行擴展，可以通過其子類來實現(xiàn)，如通過子類OracleDBUtil來連接Oracle數(shù)據(jù)庫。由于CustomerDAO針對DBUtil編程，根據(jù)里氏代換原則，DBUtil子類的對象可以覆蓋DBUtil對象，只需在CustomerDAO中注入子類對象即可使用子類所擴展的方法。例如在CustomerDAO中注入OracleDBUtil對象，即可實現(xiàn)Oracle數(shù)據(jù)庫連接，原有代碼無須進行修改，而且還可以很靈活地增加新的數(shù)據(jù)庫連接方式。

面向?qū)ο笤O計原則之迪米特法則：

迪米特法則來自于1987年美國東北大學(Northeastern University)一個名為“Demeter”的研究項目。迪米特法則又稱為最少知道原則(LeastKnowledge Principle, LKP)，其定義如下：

迪米特法則(Law of Demeter, LoD)：一個軟件實體應當盡可能少地與其他實體發(fā)生相互作用。

如果一個系統(tǒng)符合迪米特法則，那么當其中某一個模塊發(fā)生修改時，就會盡量少地影響其他模塊，擴展會相對容易，這是對軟件實體之間通信的限制，迪米特法則要求限制軟件實體之間通信的寬度和深度。迪米特法則可降低系統(tǒng)的耦合度，使類與類之間保持松散的耦合關系。

迪米特法則還有幾種定義形式，包括：不要和“陌生人”說話、只與你的直接朋友通信等，在迪米特法則中，對于一個對象，其朋友包括以下幾類：

(1) 當前對象本身(this)；

(2) 以參數(shù)形式傳入到當前對象方法中的對象；

(3) 當前對象的成員對象；

(4) 如果當前對象的成員對象是一個集合，那么集合中的元素也都是朋友；

(5) 當前對象所創(chuàng)建的對象。

任何一個對象，如果滿足上面的條件之一，就是當前對象的“朋友”，否則就是“陌生人”。在應用迪米特法則時，一個對象只能與直接朋友發(fā)生交互，不要與“陌生人”發(fā)生直接交互，這樣做可以降低系統(tǒng)的耦合度，一個對象的改變不會給太多其他對象帶來影響。

迪米特法則要求我們在設計系統(tǒng)時，應該盡量減少對象之間的交互，如果兩個對象之間不必彼此直接通信，那么這兩個對象就不應當發(fā)生任何直接的相互作用，如果其中的一個對象需要調(diào)用另一個對象的某一個方法的話，可以通過第三者轉(zhuǎn)發(fā)這個調(diào)用。簡言之，就是通過引入一個合理的第三者來降低現(xiàn)有對象之間的耦合度。

在將迪米特法則運用到系統(tǒng)設計中時，要注意下面的幾點：在類的劃分上，應當盡量創(chuàng)建松耦合的類，類之間的耦合度越低，就越有利于復用，一個處在松耦合中的類一旦被修改，不會對關聯(lián)的類造成太大波及；在類的結構設計上，每一個類都應當盡量降低其成員變量和成員函數(shù)的訪問權限；在類的設計上，只要有可能，一個類型應當設計成不變類；在對其他類的引用上，一個對象對其他對象的引用應當降到最低。

下面通過一個簡單實例來加深對迪米特法則的理解：

Sunny軟件公司所開發(fā)CRM系統(tǒng)包含很多業(yè)務操作窗口，在這些窗口中，某些界面控件之間存在復雜的交互關系，一個控件事件的觸發(fā)將導致多個其他界面控件產(chǎn)生響應，例如，當一個按鈕(Button)被單擊時，對應的列表框(List)、組合框(ComboBox)、文本框(TextBox)、文本標簽(Label)等都將發(fā)生改變，在初始設計方案中，界面控件之間的交互關系可簡化為如圖13所示結構：

圖13 初始設計方案結構圖

在圖13中，由于界面控件之間的交互關系復雜，導致在該窗口中增加新的界面控件時需要修改與之交互的其他控件的源代碼，系統(tǒng)擴展性較差，也不便于增加和刪除新控件。

現(xiàn)使用迪米特對其進行重構。

在本實例中，可以通過引入一個專門用于控制界面控件交互的中間類(Mediator)來降低界面控件之間的耦合度。引入中間類之后，界面控件之間不再發(fā)生直接引用，而是將請求先轉(zhuǎn)發(fā)給中間類，再由中間類來完成對其他控件的調(diào)用。當需要增加或刪除新的控件時，只需修改中間類即可，無須修改新增控件或已有控件的源代碼，重構后結構如圖14所示：

圖14 重構后的結構圖

總結：

單一職責原則: 一個類只負責一個職責

開閉原則: 開放擴展，封閉修改

里氏替換原則: 父類對象替換成子類對象能保證功能正常

依賴倒轉(zhuǎn)原則: 只依賴于抽象類或者接口，不依賴具體實現(xiàn)類

接口隔離原則: 接口單一職責原則，接口最小化

組合復用原則: 少用繼承，多組合復用

迪米特法則: 不需要直接通信的對象可以加一層中轉(zhuǎn)，降低依賴