若是說開閉原則是面向對象設計的目標的話,那麼依賴倒轉原則就是面向對象設計的主要實現機制之一,它是系統抽象化的具體實現。依賴倒轉原則是Robert C. Martin在1996年爲「C++Reporter」所寫的專欄Engineering Notebook的第三篇,後來加入到他在2002年出版的經典著做「Agile Software Development, Principles, Patterns, and Practices」一書中。依賴倒轉原則定義以下:html
依賴倒轉原則(Dependency Inversion Principle, DIP):抽象不該該依賴於細節,細節應當依賴於抽象。換言之,要針對接口編程,而不是針對實現編程。數據庫 |
依賴倒轉原則要求咱們在程序代碼中傳遞參數時或在關聯關係中,儘可能引用層次高的抽象層類,即便用接口和抽象類進行變量類型聲明、參數類型聲明、方法返回類型聲明,以及數據類型的轉換等,而不要用具體類來作這些事情。爲了確保該原則的應用,一個具體類應當只實現接口或抽象類中聲明過的方法,而不要給出多餘的方法,不然將沒法調用到在子類中增長的新方法。編程
在引入抽象層後,系統將具備很好的靈活性,在程序中儘可能使用抽象層進行編程,而將具體類寫在配置文件中,這樣一來,若是系統行爲發生變化,只須要對抽象層進行擴展,並修改配置文件,而無須修改原有系統的源代碼,在不修改的狀況下來擴展系統的功能,知足開閉原則的要求。函數
在實現依賴倒轉原則時,咱們須要針對抽象層編程,而將具體類的對象經過依賴注入(DependencyInjection, DI)的方式注入到其餘對象中,依賴注入是指當一個對象要與其餘對象發生依賴關係時,經過抽象來注入所依賴的對象。經常使用的注入方式有三種,分別是:構造注入,設值注入(Setter注入)和接口注入。構造注入是指經過構造函數來傳入具體類的對象,設值注入是指經過Setter方法來傳入具體類的對象,而接口注入是指經過在接口中聲明的業務方法來傳入具體類的對象。這些方法在定義時使用的是抽象類型,在運行時再傳入具體類型的對象,由子類對象來覆蓋父類對象。編碼
|
下面經過一個簡單實例來加深對依賴倒轉原則的理解:對象
Sunny軟件公司開發人員在開發某CRM系統時發現:該系統常常須要將存儲在TXT或Excel文件中的客戶信息轉存到數據庫中,所以須要進行數據格式轉換。在客戶數據操做類中將調用數據格式轉換類的方法實現格式轉換和數據庫插入操做,初始設計方案結構如圖1所示:接口 圖1 初始設計方案結構圖 在編碼實現圖1所示結構時,Sunny軟件公司開發人員發現該設計方案存在一個很是嚴重的問題,因爲每次轉換數據時數據來源不必定相同,所以須要更換數據轉換類,若有時候須要將TXTDataConvertor改成ExcelDataConvertor,此時,須要修改CustomerDAO的源代碼,並且在引入並使用新的數據轉換類時也不得不修改CustomerDAO的源代碼,系統擴展性較差,違反了開閉原則,現須要對該方案進行重構。 |
在本實例中,因爲CustomerDAO針對具體數據轉換類編程,所以在增長新的數據轉換類或者更換數據轉換類時都不得不修改CustomerDAO的源代碼。咱們能夠經過引入抽象數據轉換類解決該問題,在引入抽象數據轉換類DataConvertor以後,CustomerDAO針對抽象類DataConvertor編程,而將具體數據轉換類名存儲在配置文件中,符合依賴倒轉原則。根據里氏代換原則,程序運行時,具體數據轉換類對象將替換DataConvertor類型的對象,程序不會出現任何問題。更換具體數據轉換類時無須修改源代碼,只須要修改配置文件;若是須要增長新的具體數據轉換類,只要將新增數據轉換類做爲DataConvertor的子類並修改配置文件便可,原有代碼無須作任何修改,知足開閉原則。重構後的結構如圖2所示:
圖2重構後的結構圖
在上述重構過程當中,咱們使用了開閉原則、里氏代換原則和依賴倒轉原則,在大多數狀況下,這三個設計原則會同時出現,開閉原則是目標,里氏代換原則是基礎,依賴倒轉原則是手段,它們相輔相成,相互補充,目標一致,只是分析問題時所站角度不一樣而已。
|
再上兩張Bob大叔的「玉照」,: