[計算機]依賴和耦合關系

1、.依 賴 和 耦 合 關 系1、依賴和耦合（Dependency and Coupling）（1）什么是依賴Rose的幫助文檔上是這樣定義“依賴”關系的：“依賴描述了兩個模型元素之間的關系，如果被依賴的模型元素發(fā)生變化就會影響到另一個模型元素。典型的，在類圖上，依賴關系表明客戶類的操作會調用服務器類的操作。”（2）什么是耦合Martin Fowler在Reducing Coupling一文中這樣描述耦合：“如果改變程序的一個模塊要求另一個模塊同時發(fā)生變化，就認為這兩個模塊發(fā)生了耦合?！?Fowler 2001注意：從上面的定義可以看出：如果模塊A調用模塊B提供的方法，或訪問模塊B中的某些數(shù)據(jù)成

2、員（當然，在面向對象開發(fā)中一般不提倡這樣做），我們就認為模塊A依賴于模塊B，模塊A和模塊B之間發(fā)生了耦合。耦合是依賴的同義詞，被定義為“兩個元素之間的一種關系，其中一個元素變化，導致另一個元素變化”。抽象耦合被定義為“若類A維護一個指向抽象類B的引用，則稱類A抽象耦合于B”。2、依賴是不可避免的（1）“分而治之”的問題處理方法對于復雜的系統(tǒng)，我們常常采用它劃分成多個模塊，這樣將能夠有效地控制模塊的復雜度，使每個模塊都易于理解和維護。（2）“分而治之”的結果是產生依賴關系l 一旦我們采用“分而治之”的處理方法后，模塊之間就必須以某種方式交換信息，也就是必然要發(fā)生某種耦合關系。l 如果某個模塊和其

3、它模塊沒有任何關聯(lián)（哪怕只是潛在的或隱含的依賴關系），我們就幾乎可以斷定，該模塊不屬于此軟件系統(tǒng)，應該從系統(tǒng)中剔除。l 如果所有模塊之間都沒有任何耦合關系，其結果必然是：整個軟件不過是多個互不相干的系統(tǒng)的簡單堆積，對每個系統(tǒng)而言，所有功能還是要在一個模塊中實現(xiàn)，這等于沒有做任何模塊的分解。（3）依賴是不可避免的因此，模塊之間必定會有這樣或那樣的依賴關系，我們永遠也不要幻想消除所有的依賴（耦合關系）。我們在類的設計時，應該首先考慮的是該類應該盡可能依賴不經常變化的“目標”-比如，系統(tǒng)的API庫或者框架中的組件-試圖令具體的、易變的模塊依賴于抽象的、穩(wěn)定的模塊的基本原則。在Java中，表示字符串的

4、是具體內String。該類是穩(wěn)定的，也就是說，它不太會改變。因此，直接依賴于它不會造成損害。既然變化不可避免，我們所能做的就是處理好依賴關系，將變化造成的影響的波及范圍盡量減小。（4）我們所追求的是盡可能降低過強的耦合關系“依賴”是和“變化”緊密聯(lián)系在一起的概念。由于依賴關系的存在，變化在某處發(fā)生時，影響會波及開去，造成很多修改工作，這就是依賴的危害。l 因為，過強的耦合關系（如一個模塊的變化會造成一個或多個其他模塊也同時發(fā)生變化的依賴關系）會對軟件系統(tǒng)的質量造成很大的危害。l 特別是當需求發(fā)生變化時，代碼的維護成本將非常高。所以，我們必須想盡辦法來控制和消解不必要的耦合，特別是那種會導致其它

5、模塊發(fā)生不可控變化的依賴關系。（5）如何達到-采用什么的策略或者方法依賴倒置、控制反轉、依賴注入等原則。3、依賴倒置（DIP-Dependency Inversion Principle）（1）什么是依賴倒置-將依賴關系倒置為依賴接口依賴倒置原則就是建立在抽象接口的基礎上的。Robert Martin這樣描述依賴倒置原則Martin 1996：l 上層模塊不應該依賴于下層模塊，它們共同依賴于一個抽象。l 抽象不能依賴于具體，具體依賴于抽象-也就是“系統(tǒng)的核心邏輯”不依賴于“具體的實現(xiàn)細節(jié)”。依賴性倒置原則形式化了抽象耦合的概念，明確表述了應該“依賴于抽象類，不要依賴于具體類”。（2）如何達到依

6、賴倒置的效果為了消解兩個模塊間的依賴關系，應該在兩個模塊之間定義一個抽象接口，上層模塊調用抽象接口定義的方法，下層模塊實現(xiàn)該接口。針對接口編程遵守上述原則，從而在很大程度上阻止了變化波及范圍的擴大，有效地隔離了變化，有助于增強系統(tǒng)的可重用性和可擴展性。（3）為什么要依賴接口l 因為抽象是相對穩(wěn)定的或者是相對變化不頻繁的，而具體是易變的因此，要使我們的設計具有很大的靈活性，就需要做到大家都依賴于抽象的東西，而利用抽象隔離具體類之間的關系，這樣使得“具體”的任何改動都可以在局部范圍內實現(xiàn)，而不影響其它的結構。比如，一個IO系統(tǒng)它必然就有READ/WRITE這兩個抽象，至于具體是磁盤還是鍵盤，那是下

7、面的實現(xiàn)不同了，通過這種構架，能保持軟件的彈性與可維護性。l 依賴抽象是我們實現(xiàn)代碼擴展和運行期內綁定（多態(tài)）的基礎因為一旦類的使用者依賴某個具體的類，那么對該依賴的擴展就無從談起；而依賴某個抽象類，則只要實現(xiàn)了該抽象類的子類，都可以被類的使用者使用，從而實現(xiàn)了系統(tǒng)的擴展。（4）示例（摘錄網(wǎng)上資料）這里舉個比較好笑的例子：一個即將做領導的兒子問曾經做領導的父親怎么才能平步青云，父親說你不能說假話，因為老百姓會不答應，也不能說實話，因為領導會對你有意見，兒子思索良久問：那我該說什么? 父親意味深長的說：空話笑話不但好笑，還能反映一定的道理，為啥空話這么有用，因為他是抽象的，而抽象不涉及到一些具體

8、的數(shù)據(jù)或者事務，因此他是穩(wěn)定的，是不容易變化的，同時基本上也是正確的。4、依據(jù)“依賴倒置原則”進行編程開發(fā)（1）體現(xiàn)倒置原則的UML類圖以前傳統(tǒng)的過程設計中是從上到下的一條依賴線現(xiàn)在是平的一條到接口，然后是一條從下往上的的關聯(lián)線。（2）其主要的優(yōu)點l 由于在依賴倒置中，通過抽象接口達到隔離了“服務的提供者”和“服務的請求者”，使它們之間沒有直接的耦合關系，兩者可以獨立地擴展或重用。l 依賴倒置原則是許多面向對象技術的優(yōu)點的根本。合理地應用它對于建立可復用的框架是必要的。對于構建富有變化彈力的代碼也是相當重要的。而且，由于抽象和具體相互完全分離，代碼的維護就容易很多了。依賴倒置原則一般應用于類與

9、類之間的代碼級的依賴關系。（3）應用依賴倒置原則的代碼示例l 任何實例對象變量都不應該持有一個指向具體類的引用，而應該為接口類型的對象聲明class SomeClass private SomeInterface obj=null;l 任何類都不應該從具體類派生，而應該實現(xiàn)某個接口-面向接口編程，而不要面向實現(xiàn)編程class SomeClass implements SomeInterface / extends SuperClass5、依賴倒置原則示例（1）持久層中的各個組件常規(guī)的設計和實現(xiàn)方案在很多Web應用系統(tǒng)中，都需要對后臺的數(shù)據(jù)庫系統(tǒng)進行訪問以實現(xiàn)數(shù)據(jù)存儲的目的。而一個常見的解決手段

10、是使用分層的設計思想和方法，將Web應用系統(tǒng)中的持久層中的各個組件分為數(shù)據(jù)訪問操作組件（DAO，Data Access Object）和數(shù)據(jù)連接組件，下面的圖中所示為這種常規(guī)的設計和實現(xiàn)方案的類圖。（2）常規(guī)設計和實現(xiàn)方案中所反映出的問題從上面的圖中的所示的數(shù)據(jù)訪問操作組件和數(shù)據(jù)連接組件之間的關系來看，兩者產生了緊密的藕合關系。一旦數(shù)據(jù)連接組件有了任何變化，數(shù)據(jù)訪問操作組件都有可能會受其影響而需要被改動。當然，如果只是針對這兩個類本身而言的話，這種依賴關系根本算不上什么問題。然而，在一個實際的應用系統(tǒng)中，數(shù)據(jù)訪問操作組件和數(shù)據(jù)連接組件都會由不只一個類而構成的，并都有一定的技術實現(xiàn)上的復雜度，這

11、時它們兩者之間的這種依賴關系就會增加系統(tǒng)的復雜性；而且隨著應用系統(tǒng)中的各個程序模塊越來越多、功能實現(xiàn)也越來越復雜時，這種由于兩者之間的緊密藕合所帶來的系統(tǒng)的復雜度會越來越高。因此，如果不限制它們之間的緊密藕合聯(lián)系，那模塊間的依賴、程序的復雜度和開發(fā)維護的難度都會成指數(shù)上升。（3）對設計進行優(yōu)化在兩者之間添加一個抽象的接口在兩者之間添加一個數(shù)據(jù)連接組件的接口，并在其中包含數(shù)據(jù)訪問操作組件中所需要的各種數(shù)據(jù)連接的服務方法的定義，而某個具體的數(shù)據(jù)連接組件則實現(xiàn)這個接口。此時數(shù)據(jù)訪問操作組件則只需要調用數(shù)據(jù)連接組件接口中的服務來實現(xiàn)數(shù)據(jù)庫的各種連接功能，兩者都只依賴于數(shù)據(jù)連接組件的接口。請見下面的圖中

12、所示的優(yōu)化設計結果的類圖。這樣，數(shù)據(jù)訪問操作組件到數(shù)據(jù)連接組件的依賴關系被數(shù)據(jù)連接組件的接口所隔離開。因為在接口中只包含了所需要的各種連接的服務功能的定義，而不包括任何連接的服務功能的具體實現(xiàn)，所以數(shù)據(jù)連接組件的接口的內容在具體設計時也會很簡單。在數(shù)據(jù)連接組件接口不變的情況下，數(shù)據(jù)訪問操作組件和某個具體的數(shù)據(jù)連接組件這兩個模塊都可以自由地進行修改而不影響到對方（比如添加另一個數(shù)據(jù)連接組件），依賴關系也變得簡單和可管理。（4）進一步改進本設計和實現(xiàn)方案核心邏輯不依賴于具體的實現(xiàn)細節(jié)如果從系統(tǒng)架構的角度來看上面的圖中所示的設計和實現(xiàn)方案還存在一定的問題，因為數(shù)據(jù)訪問操作組件所提供的功能是整個應用系

13、統(tǒng)的數(shù)據(jù)訪問的核心部分，而數(shù)據(jù)連接組件中的各個功能方法則可以看成是具體實現(xiàn)的的細節(jié)。因此，從這個角度來看圖中優(yōu)化設計后的結果時，該設計是“核心邏輯依賴于具體的實現(xiàn)細節(jié)”。當然，也就沒有遵守依賴倒置原則中的“抽象不能依賴于具體，具體依賴于抽象”的要求。因為，當細節(jié)變化（數(shù)據(jù)連接中的數(shù)據(jù)源或者連接方式發(fā)生變化）時，數(shù)據(jù)訪問操作組件中的核心邏輯（數(shù)據(jù)訪問的實現(xiàn)邏輯）也會受到一定的影響。因為當應用系統(tǒng)中的數(shù)據(jù)存儲從某一種形式的數(shù)據(jù)庫系統(tǒng)改變另一種形式的數(shù)據(jù)庫系統(tǒng)（比如從微軟的MS SQLServer2000改變?yōu)镺racle10G數(shù)據(jù)庫系統(tǒng)）時，此時也將必然會影響到數(shù)據(jù)訪問操作組件中有關的的具體實現(xiàn)方

14、法（因為對這兩種不同的數(shù)據(jù)庫系統(tǒng)在具體進行數(shù)據(jù)訪問操作實現(xiàn)時的SQL語句或者涉及對存儲過程的調用時，是不一樣的?。榱四軌蜻_到當系統(tǒng)中的數(shù)據(jù)庫類型發(fā)生變化時，不至于影響到對數(shù)據(jù)庫訪問組件的使用者（業(yè)務層組件）的代碼，有必要對系統(tǒng)設計進一步完善！下面的圖所示為這樣的應用場景下的各個類的設計要求的圖示。（5）利用數(shù)據(jù)庫訪問操作的抽象接口進行隔離因此，有必要對上面的圖中所體現(xiàn)出的設計結果進一步地改進和完善。主要的思路是將由于數(shù)據(jù)庫連接方式的不同而造成的數(shù)據(jù)庫訪問操作的不同隔離開，在數(shù)據(jù)庫訪問操作這一層次同樣也設計出一個數(shù)據(jù)庫訪問操作的抽象接口，并為該數(shù)據(jù)庫訪問操作的抽象接口提供不同的具體數(shù)據(jù)庫訪問

15、操作的實現(xiàn)類。這樣的設計能夠避免改動對數(shù)據(jù)庫訪問操作的使用類（一般為上層的業(yè)務層組件類）的代碼，下面的圖為進一步完善后的設計結果的類圖。控制反轉（Ioc-Inversion of Control）1、消解框架和我們的應用系統(tǒng)類之間的依賴關系前面依賴倒置原則描述的是類與類之間的代碼級的依賴關系。如果我們開發(fā)的系統(tǒng)是基于某種框架系統(tǒng)來開發(fā)的，此時我們的類對目標框架的依賴關系就會更強烈一點。那么，該如何消解框架和我們的應用系統(tǒng)類之間的依賴關系呢？利用控制反轉。2、控制反轉（1）什么是控制反轉“好萊塢原則（不要調用我們，讓我們調用你）”。（2）面向框架和面向系統(tǒng)類庫開發(fā)的不同點l 框架和類庫最重要的區(qū)

16、別是：框架是一個半成品的應用程序，而類庫只包含一系列可被應用程序調用的類。l 類庫給用戶提供了一系列可復用的類，這些類的設計都符合面向對象原則和模式。用戶使用時，可以創(chuàng)建這些類的實例，或從這些類中繼承出新的派生類，然后調用類中相應的功能。在這一過程中，類庫總是被動地響應用戶的調用請求。l 框架則會為某一特定目的實現(xiàn)一個基本的、可執(zhí)行的架構?？蚣苤幸呀洶藨贸绦驈膯拥竭\行的主要流程，流程中那些無法預先確定的步驟留給用戶來實現(xiàn)。程序運行時，框架系統(tǒng)自動調用用戶實現(xiàn)的功能組件。這時，框架系統(tǒng)的行為是主動的。（3）應用系統(tǒng)和框架系統(tǒng)之間的依賴關系有以下特點l 應用系統(tǒng)和框架系統(tǒng)之間實際上是雙向調

17、用，雙向依賴的關系。l 通過依賴倒置原則可以減弱應用系統(tǒng)到框架系統(tǒng)之間的依賴關系。l 而利用“控制反轉”及具體的模板方法模式可以消解框架到應用系統(tǒng)之間的依賴關系，這也是所有框架系統(tǒng)的基礎。l 框架系統(tǒng)通過“控制反轉”，最后能夠達到可以獨立地被重用。（4）“控制反轉”的體現(xiàn)傳統(tǒng)的面向類庫的做法，我們在自己的程序中調用一個個類庫去完成一個個功能，類庫是我們的執(zhí)行體，但是邏輯算法等是自己實現(xiàn)的，這就是自己的控制。但由于了框架后則不一樣，邏輯算法都是它來實現(xiàn)，我們只要提供它幾個需要的接口或者執(zhí)行體就可。這就是反轉，控制在框架這邊了-由框架來對我們的代碼進行調用。其目的主要是簡化工作量，對于一些常見的業(yè)

18、務場景不需要自己去重復實現(xiàn)。3、應用框架是如何實現(xiàn)控制反轉（1）利用模板方法模式為上層的應用系統(tǒng)提供“模板方法模式”，因為在面向對象領域，“回調函數(shù)”（一般是面向系統(tǒng)類庫開發(fā)時采用的手段）的替代物就是“模板方法模式”（ 一般是面向應用框架開發(fā)時采用的手段）。（2）什么是模板方法模式“模板方法模式”，也就是“好萊塢原則（不要調用我們，讓我們調用你）”。模板方法模式是框架系統(tǒng)的基礎，任何框架系統(tǒng)都離不開模板方法模式如Struts框架中的插件技術public final class UserDatabasePlugIn implements PlugInpublic void destroy() p

19、ublic void init(ActionServlet servlet, ModuleConfig config) throws ServletException（3）Spring 框架中的TransactionTemplate模板類的代碼【例11-34】 TransactionTemplate模板類的部分代碼示例package org.springframework.transaction.support;/ import語句，在此加以省略public class TransactionTemplate extends DefaultTransactionDefinition imple

20、ments InitializingBeanpublic Object execute(TransactionCallback action) throws TransactionException if (this.transactionManager instanceof CallbackPreferringPlatformTransactionManager) return (CallbackPreferringPlatformTransactionManager) this.transactionManager).execute(this, action);else Transacti

21、onStatus status =this.transactionManager.getTransaction(this);Object result = null;try /對用戶的實現(xiàn)類中的doInTransaction方法進行回調 result = action.doInTransaction(status); catch (RuntimeException ex) /用戶的回調方法執(zhí)行失敗時將自動地進行事務回滾rollbackOnException(status, ex);throw ex;catch (Error err) /用戶的回調方法執(zhí)行失敗時將自動地進行事務回滾rollbac

22、kOnException(status, err);throw err; /用戶的回調方法執(zhí)行成功將自動地進行事務提交this.transactionMmit(status); return result;/ 其它的方法定義，在此加以省略在下面的【例11-35】中所示的是TransactionCallback接口的代碼定義示例，該接口只有一個doInTransaction方法的聲明。該方法也就是前面的TransactionTemplate模板類中的“回調”方法（或者是“鉤子”方法）?！纠?1-35】TransactionCallback接口的定義的代碼示例package org.springf

23、ramework.transaction.support;import org.springframework.transaction.TransactionStatus;public interface TransactionCallback Object doInTransaction(TransactionStatus status);4、“控制反轉”和“依賴倒置”的不同點雖然“依賴倒置”和“控制反轉”在設計層面上都是消解模塊耦合的有效方法，也都是試圖令具體的、易變的模塊依賴于抽象的、穩(wěn)定的模塊的基本原則，但二者在使用語境和關注點上存在差異。（1）“倒置”的目標不同“依賴倒置”強調的是對于傳統(tǒng)的、源于面向過程設計思想的層次概念的“倒置”，而“控制反轉”強調的是對程序流程控制權的反轉；（2）應用的范圍不同“依賴倒置”的使用范圍更為寬泛，既可用于對程序流程的描述（如流程的主從和層次關系），也可用于描述其他擁有概念層次的設計模型（如服務組件與客戶組件、核心模塊與外圍應用等）。而“控制反轉”則僅適用于描述流程控制權的場合（如算法流程或業(yè)務流程的控制權）。我們也可以把“