【2019年整理】依賴和耦合關(guān)系

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

2、法，或訪問模塊 B 中的某些數(shù)據(jù)成員（當(dāng) 然，在面向?qū)ο箝_發(fā)中一般不提倡這樣做） ，我們就認(rèn)為模塊 A 依賴于模塊 B ，模塊 A 和模塊 B 之間發(fā)生 了耦合。 耦合是依賴的同義詞，被定義為“兩個元素之間的一種關(guān)系，其中一個元素變化，導(dǎo)致另一個元素變 化”。抽象耦合被定義為“若類 A 維護(hù)一個指向抽象類 B 的引用，則稱類 A 抽象耦合于 B”。 2、依賴是不可避免的 （ 1）“分而治之”的問題處理方法 對于復(fù)雜的系統(tǒng)，我們常常采用它劃分成多個模塊，這樣將能夠有效地控制模塊的復(fù)雜度，使每個模 塊都易于理解和維護(hù)。 （ 2）“分而治之”的結(jié)果是產(chǎn)生依賴關(guān)系 一旦我們采用 “分而治之”的處理方法

3、后， 模塊之間就必須以某種方式交換信息，也就是必然要 發(fā)生某種耦合關(guān)系。 如果某個模塊和其它模塊沒有任何關(guān)聯(lián)（哪怕只是潛在的或隱含的依賴關(guān)系） ，我們就幾乎可以 斷定，該模塊不屬于此軟件系統(tǒng)，應(yīng)該從系統(tǒng)中剔除。 如果所有模塊之間都沒有任何耦合關(guān)系，其結(jié)果必然是：整個軟件不過是多個互不相干的系統(tǒng)的 簡單堆積， 對每個系統(tǒng)而言， 所有功能還是要在一個模塊中實(shí)現(xiàn)， 這等于沒有做任何模塊的分解。 （ 3）依賴是不可避免的 因此，模塊之間必定會有這樣或那樣的依賴關(guān)系， 我們永遠(yuǎn)也不要幻想消除所有的依賴（耦合關(guān)系） 。 我們在類的設(shè)計(jì)時，應(yīng)該首先考慮的是該類應(yīng)該盡可能依賴不經(jīng)常變化的“目標(biāo)” 比如，系統(tǒng)的

4、 API 庫或者框架中的組件 試圖令具體的、易變的模塊依賴于抽象的、穩(wěn)定的模塊的基本原則。 在 Java 中，表示字符串的是具體內(nèi) String 。該類是穩(wěn)定的，也就是說，它不太會改變。因此，直接依 賴于它不會造成損害。 既然變化不可避免，我們所能做的就是處理好依賴關(guān)系，將變化造成的影響的波及范圍盡量減小。 （ 4）我們所追求的是盡可能降低過強(qiáng)的耦合關(guān)系 “依賴”是和“變化”緊密聯(lián)系在一起的概念。由于依賴關(guān)系的存在，變化在某處發(fā)生時，影響會波 及開去，造成很多修改工作，這就是依賴的危害。 因?yàn)?，過強(qiáng)的耦合關(guān)系（如一個模塊的變化會造成一個或多個其他模塊也同時發(fā)生變化的依賴關(guān) 系）會對軟件系統(tǒng)的質(zhì)

5、量造成很大的危害。 特別是當(dāng)需求發(fā)生變化時，代碼的維護(hù)成本將非常高。所以，我們必須想盡辦法來控制和消解不 必要的耦合，特別是那種會導(dǎo)致其它模塊發(fā)生不可控變化的依賴關(guān)系。 （ 5）如何達(dá)到 采用什么的策略或者方法 依賴倒置、控制反轉(zhuǎn)、依賴注入等原則。 3、依賴倒置（ DIPDependency Inversion Principle ） （ 1）什么是依賴倒置 將依賴關(guān)系倒置為依賴接口 依賴倒置原則就是建立在抽象接口的基礎(chǔ)上的。 Robert Martin 這樣描述依賴倒置原則 Martin 1996 ： 上層模塊不應(yīng)該依賴于下層模塊，它們共同依賴于一個抽象。 也就是“系統(tǒng)的核心邏輯”不依賴于“

6、具體的實(shí)現(xiàn)細(xì) 抽象不能依賴于具體，具體依賴于抽象 節(jié)”。 依賴性倒置原則形式化了抽象耦合的概念，明確表述了應(yīng)該“依賴于抽象類，不要依賴于具體類” （2）如何達(dá)到依賴倒置的效果 為了消解兩個模塊間的依賴關(guān)系，應(yīng)該在兩個模塊之間定義一個抽象接口，上層模塊調(diào)用抽象接口定 義的方法，下層模塊實(shí)現(xiàn)該接口。 針對接口編程遵守上述原則，從而在很大程度上阻止了變化波及范圍的擴(kuò)大，有效地隔離了變化，有 助于增強(qiáng)系統(tǒng)的可重用性和可擴(kuò)展性。 （3）為什么要依賴接口 因?yàn)槌橄笫窍鄬Ψ€(wěn)定的或者是相對變化不頻繁的，而具體是易變的 因此，要使我們的設(shè)計(jì)具有很大的靈活性，就需要做到大家都依賴于抽象的東西，而利用抽象隔離具 體

7、類之間的關(guān)系，這樣使得“具體”的任何改動都可以在局部范圍內(nèi)實(shí)現(xiàn)，而不影響其它的結(jié)構(gòu)。 比如，一個10系統(tǒng)它必然就有 READ/WRITE這兩個抽象，至于具體是磁盤還是鍵盤，那是下面的實(shí) 現(xiàn)不同了，通過這種構(gòu)架，能保持軟件的彈性與可維護(hù)性。 依賴抽象是我們實(shí)現(xiàn)代碼擴(kuò)展和運(yùn)行期內(nèi)綁定（多態(tài)）的基礎(chǔ) 因?yàn)橐坏╊惖氖褂谜咭蕾嚹硞€具體的類，那么對該依賴的擴(kuò)展就無從談起；而依賴某個抽象類，則只 要實(shí)現(xiàn)了該抽象類的子類，都可以被類的使用者使用，從而實(shí)現(xiàn)了系統(tǒng)的擴(kuò)展。 （4）示例（摘錄網(wǎng)上資料） 這里舉個比較好笑的例子：一個即將做領(lǐng)導(dǎo)的兒子問曾經(jīng)做領(lǐng)導(dǎo)的父親怎么才能平步青云，父親說你 不能說假話，因?yàn)槔习傩諘?/p>

8、不答應(yīng)，也不能說實(shí)話，因?yàn)轭I(lǐng)導(dǎo)會對你有意見，兒子思索良久問：那我該說 什么？父親意味深長的說：空話 笑話不但好笑，還能反映一定的道理，為啥空話這么有用，因?yàn)樗浅橄蟮?，而抽象不涉及到一些?體的數(shù)據(jù)或者事務(wù)，因此他是穩(wěn)定的，是不容易變化的，同時基本上也是正確的。 4、依據(jù)“依賴倒置原則”進(jìn)行編程開發(fā) （1）體現(xiàn)倒置原則的 UML類圖 以前傳統(tǒng)的過程設(shè)計(jì)中是從上到下的一條依賴線 類的使用者服務(wù)的請求者） 接口的實(shí)現(xiàn)類（服務(wù)提供者） 現(xiàn)在是平的一條到接口，然后是一條從下往上的的關(guān)聯(lián)線。 （2）其主要的優(yōu)點(diǎn) 由于在依賴倒置中，通過抽象接口達(dá)到隔離了“服務(wù)的提供者”和“服務(wù)的請求者”，使它們之 間沒有

9、直接的耦合關(guān)系，兩者可以獨(dú)立地?cái)U(kuò)展或重用。 依賴倒置原則是許多面向?qū)ο蠹夹g(shù)的優(yōu)點(diǎn)的根本。合理地應(yīng)用它對于建立可復(fù)用的框架是必要 的。對于構(gòu)建富有變化彈力的代碼也是相當(dāng)重要的。而且，由于抽象和具體相互完全分離，代碼 的維護(hù)就容易很多了。 依賴倒置原則一般應(yīng)用于類與類之間的代碼級的依賴關(guān)系。 （3）應(yīng)用依賴倒置原則的代碼示例 任何實(shí)例對象變量都不應(yīng)該持有一個指向具體類的引用，而應(yīng)該為接口類型的對象聲明 class SomeClass private Some In terface obj=n ull; 任何類都不應(yīng)該從具體類派生，而應(yīng)該實(shí)現(xiàn)某個接口-面向接口編程，而不要面向?qū)崿F(xiàn)編程 class S

10、omeClassimpleme nts SomeI nterface / exte nds SuperClass 5、依賴倒置原則示例 （1）持久層中的各個組件常規(guī)的設(shè)計(jì)和實(shí)現(xiàn)方案 在很多Web應(yīng)用系統(tǒng)中，都需要對后臺的數(shù)據(jù)庫系統(tǒng)進(jìn)行訪問以實(shí)現(xiàn)數(shù)據(jù)存儲的目的。而一個常見的 解決手段是使用分層的設(shè)計(jì)思想和方法，將Web應(yīng)用系統(tǒng)中的持久層中的各個組件分為數(shù)據(jù)訪問操作組件 （DAQ Data Access Object ）和數(shù)據(jù)連接組件，下面的圖中所示為這種常規(guī)的設(shè)計(jì)和實(shí)現(xiàn)方案的類圖。 （2）常規(guī)設(shè)計(jì)和實(shí)現(xiàn)方案中所反映出的問題 從上面的圖中的所示的 數(shù)據(jù)訪問操作組件 和數(shù)據(jù)連接組件 之間的關(guān)系來看，

11、兩者產(chǎn)生了緊密的藕合關(guān) 系。一旦數(shù)據(jù)連接組件有了任何變化，數(shù)據(jù)訪問操作組件都有可能會受其影響而需要被改動。 當(dāng)然，如果只是針對這兩個類本身而言的話，這種依賴關(guān)系根本算不上什么問題。然而，在一個實(shí)際 的應(yīng)用系統(tǒng)中，數(shù)據(jù)訪問操作組件和數(shù)據(jù)連接組件都會由不只一個類而構(gòu)成的，并都有一定的技術(shù)實(shí)現(xiàn)上 的復(fù)雜度，這時它們兩者之間的這種依賴關(guān)系就會增加系統(tǒng)的復(fù)雜性；而且隨著應(yīng)用系統(tǒng)中的各個程序模 塊越來越多、功能實(shí)現(xiàn)也越來越復(fù)雜時，這種由于兩者之間的緊密藕合所帶來的系統(tǒng)的復(fù)雜度會越來越高。 因此，如果不限制它們之間的緊密藕合聯(lián)系，那模塊間的依賴、程序的復(fù)雜度和開發(fā)維護(hù)的難度都會成指 數(shù)上升。 （3）對設(shè)計(jì)進(jìn)

12、行優(yōu)化在兩者之間添加一個抽象的接口 在兩者之間添加一個數(shù)據(jù)連接組件的接口，并在其中包含數(shù)據(jù)訪問操作組件中所需要的各種數(shù)據(jù)連接 的服務(wù)方法的定義，而某個具體的數(shù)據(jù)連接組件則實(shí)現(xiàn)這個接口。此時數(shù)據(jù)訪問操作組件則只需要調(diào)用數(shù) 據(jù)連接組件接口中的服務(wù)來實(shí)現(xiàn)數(shù)據(jù)庫的各種連接功能，兩者都只依賴于數(shù)據(jù)連接組件的接口。請見下面 的圖中所示的優(yōu)化設(shè)計(jì)結(jié)果的類圖。 這樣，數(shù)據(jù)訪問操作組件到數(shù)據(jù)連接組件的依賴關(guān)系被數(shù)據(jù)連接組件的接口所隔離開。因?yàn)樵诮涌谥?只包含了所需要的各種連接的服務(wù)功能的定義，而不包括任何連接的服務(wù)功能的具體實(shí)現(xiàn)，所以數(shù)據(jù)連接 組件的接口的內(nèi)容在具體設(shè)計(jì)時也會很簡單。在數(shù)據(jù)連接組件接口不變的情況

13、下，數(shù)據(jù)訪問操作組件和某 個具體的數(shù)據(jù)連接組件這兩個模塊都可以自由地進(jìn)行修改而不影響到對方（比如添加另一個數(shù)據(jù)連接組 件），依賴關(guān)系也變得簡單和可管理。 （4）進(jìn)一步改進(jìn)本設(shè)計(jì)和實(shí)現(xiàn)方案一一核心邏輯不依賴于具體的實(shí)現(xiàn)細(xì)節(jié) 如果從系統(tǒng)架構(gòu)的角度來看上面的圖中所示的設(shè)計(jì)和實(shí)現(xiàn)方案還存在一定的問題，因?yàn)閿?shù)據(jù)訪問操作 組件所提供的功能是整個應(yīng)用系統(tǒng)的數(shù)據(jù)訪問的核心部分，而數(shù)據(jù)連接組件中的各個功能方法則可以看成 是具體實(shí)現(xiàn)的的細(xì)節(jié)。因此，從這個角度來看圖中優(yōu)化設(shè)計(jì)后的結(jié)果時，該設(shè)計(jì)是“核心邏輯依賴于具體 的實(shí)現(xiàn)細(xì)節(jié)”。當(dāng)然，也就沒有遵守依賴倒置原則中的“抽象不能依賴于具體，具體依賴于抽象”的要求。 因?yàn)?/p>

14、，當(dāng)細(xì)節(jié)變化（數(shù)據(jù)連接中的數(shù)據(jù)源或者連接方式發(fā)生變化）時，數(shù)據(jù)訪問操作組件中的核心邏 輯（數(shù)據(jù)訪問的實(shí)現(xiàn)邏輯）也會受到一定的影響。因?yàn)楫?dāng)應(yīng)用系統(tǒng)中的數(shù)據(jù)存儲從某一種形式的數(shù)據(jù)庫系 統(tǒng)改變另一種形式的數(shù)據(jù)庫系統(tǒng)（比如從微軟的MS SQLServer2000改變?yōu)镺raclelOG數(shù)據(jù)庫系統(tǒng)）時， 此時也將必然會影響到數(shù)據(jù)訪問操作組件中有關(guān)的的具體實(shí)現(xiàn)方法（因?yàn)閷@兩種不同的數(shù)據(jù)庫系統(tǒng)在具 體進(jìn)行數(shù)據(jù)訪問操作實(shí)現(xiàn)時的SQL語句或者涉及對存儲過程的調(diào)用時，是不一樣的！）。 為了能夠達(dá)到當(dāng)系統(tǒng)中的數(shù)據(jù)庫類型發(fā)生變化時，不至于影響到對數(shù)據(jù)庫訪問組件的使用者（業(yè)務(wù)層 組件）的代碼，有必要對系統(tǒng)設(shè)計(jì)進(jìn)一步完

15、善！下面的圖所示為這樣的應(yīng)用場景下的各個類的設(shè)計(jì)要求的 圖示。 (5) 利用數(shù)據(jù)庫訪問操作的抽象接口進(jìn)行隔離 因此，有必要對上面的圖中所體現(xiàn)出的設(shè)計(jì)結(jié)果進(jìn)一步地改進(jìn)和完善。主要的思路是將由于數(shù)據(jù)庫連 接方式的不同而造成的數(shù)據(jù)庫訪問操作的不同隔離開，在數(shù)據(jù)庫訪問操作這一層次同樣也設(shè)計(jì)出一個數(shù)據(jù) 庫訪問操作的抽象接口，并為該數(shù)據(jù)庫訪問操作的抽象接口提供不同的具體數(shù)據(jù)庫訪問操作的實(shí)現(xiàn)類。 這樣的設(shè)計(jì)能夠避免改動對數(shù)據(jù)庫訪問操作的使用類(一般為上層的業(yè)務(wù)層組件類)的代碼，下面的 圖為進(jìn)一步完善后的設(shè)計(jì)結(jié)果的類圖。 控制反轉(zhuǎn)(loc-lnversion of Control) 1消解框架和我們的應(yīng)用系統(tǒng)

16、類之間的依賴關(guān)系 前面依賴倒置原則描述的是類與類之間的代碼級的依賴關(guān)系。如果我們開發(fā)的系統(tǒng)是基于某種框架系 統(tǒng)來開發(fā)的，此時我們的類對目標(biāo)框架的依賴關(guān)系就會更強(qiáng)烈一點(diǎn)。那么，該如何消解框架和我們的應(yīng)用 系統(tǒng)類之間的依賴關(guān)系呢？利用控制反轉(zhuǎn)。 2、控制反轉(zhuǎn) （1）什么是控制反轉(zhuǎn) “好萊塢原則（不要調(diào)用我們，讓我們調(diào)用你）”。 （2）面向框架和面向系統(tǒng)類庫開發(fā)的不同點(diǎn) 框架和類庫最重要的區(qū)別是：框架是一個半成品的應(yīng)用程序，而類庫只包含一系列可被應(yīng)用 程序調(diào)用的類。 類庫給用戶提供了一系列可復(fù)用的類，這些類的設(shè)計(jì)都符合面向?qū)ο笤瓌t和模式。用戶使用時， 可以創(chuàng)建這些類的實(shí)例，或從這些類中繼承出新的派生

17、類，然后調(diào)用類中相應(yīng)的功能。在這一過 程中，類庫總是被動地響應(yīng)用戶的調(diào)用請求。 框架則會為某一特定目的實(shí)現(xiàn)一個基本的、可執(zhí)行的架構(gòu)?？蚣苤幸呀?jīng)包含了應(yīng)用程序從啟動到 運(yùn)行的主要流程，流程中那些無法預(yù)先確定的步驟留給用戶來實(shí)現(xiàn)。程序運(yùn)行時，框架系統(tǒng)自動 調(diào)用用戶實(shí)現(xiàn)的功能組件。這時，框架系統(tǒng)的行為是主動的。 （3）應(yīng)用系統(tǒng)和框架系統(tǒng)之間的依賴關(guān)系有以下特點(diǎn) 應(yīng)用系統(tǒng)和框架系統(tǒng)之間實(shí)際上是雙向調(diào)用，雙向依賴的關(guān)系。 通過依賴倒置原則可以減弱應(yīng)用系統(tǒng)到框架系統(tǒng)之間的依賴關(guān)系。 而利用“控制反轉(zhuǎn)”及具體的模板方法模式可以消解框架到應(yīng)用系統(tǒng)之間的依賴關(guān)系，這也是所 有框架系統(tǒng)的基礎(chǔ)。 框架系統(tǒng)通過“控制

18、反轉(zhuǎn)”，最后能夠達(dá)到可以獨(dú)立地被重用。 （4）“控制反轉(zhuǎn)”的體現(xiàn) 傳統(tǒng)的面向類庫的做法，我們在自己的程序中調(diào)用一個個類庫去完成一個個功能，類庫是我們的執(zhí)行 體，但是邏輯算法等是自己實(shí)現(xiàn)的，這就是自己的控制。 但由于了框架后則不一樣，邏輯算法都是它來實(shí)現(xiàn)，我們只要提供它幾個需要的接口或者執(zhí)行體就可。 這就是反轉(zhuǎn)，控制在框架這邊了-由框架來對我們的代碼進(jìn)行調(diào)用。 其目的主要是簡化工作量，對于一些常見的業(yè)務(wù)場景不需要自己去重復(fù)實(shí)現(xiàn)。 3、應(yīng)用框架是如何實(shí)現(xiàn)控制反轉(zhuǎn) （1）利用模板方法模式 為上層的應(yīng)用系統(tǒng)提供“模板方法模式”，因?yàn)樵诿嫦驅(qū)ο箢I(lǐng)域，“回調(diào)函數(shù)”（一般是面向系統(tǒng)類庫 開發(fā)時采用的手段）的

19、替代物就是“模板方法模式”（一般是面向應(yīng)用框架開發(fā)時采用的手段）。 評昨蓋的鉤子加，實(shí)眼 （2）什么是模板方法模式 “模板方法模式”，也就是“好萊塢原則（不要調(diào)用我們，讓我們調(diào)用你） 統(tǒng)的基礎(chǔ)，任何框架系統(tǒng)都離不開模板方法模式 如Struts框架中的插件技術(shù) public final class UserDatabasePlugI n public void destroy（） public （3）Spring 【例11-34】 ”。模板方法模式是框架系 impleme nts Plugin void init(ActionServlet servlet,ModuleCo nfig con f

20、ig) throws ServletExceptio n 框架中的TransactionTemplate模板類的代碼 TransactionTemplate模板類的部分代碼示例 package org.springframework.transaction.support; / import 語句，在此加以省略 publicclassTransactionTemplate DefaultTransactionDefinition implements InitializingBean extends public Object execute(TransactionCallback Trans

21、actionException if (this.transactionManager instanceof action) throws CHINA-PUB.COM 円見詆上匕S A - CallbackPreferringPlatformTransactionManager) return (CallbackPreferringPlatformTransactionManager) this.transactionManager). execute(this, action); else TransactionStatus status =this.transactionManager.g

22、etTransaction(this); Object result = null; try / 對用戶的實(shí)現(xiàn)類中的 doInTransaction 方法進(jìn)行回調(diào) result = action.doInTransaction(status); catch (RuntimeException ex) / 用戶的回調(diào)方法執(zhí)行失敗時將自動地進(jìn)行事務(wù)回滾 rollbackOnException(status, ex); throw ex; catch (Error err) / 用戶的回調(diào)方法執(zhí)行失敗時將自動地進(jìn)行事務(wù)回滾 rollbackOnException(status, err); thro

23、w err; / 用戶的回調(diào)方法執(zhí)行成功將自動地進(jìn)行事務(wù)提交 this.transactionMmit(status); return result; / 其它的方法定義，在此加以省略 在下面的【例 11-35 】中所示的是 TransactionCallback 接口的代碼定義示例，該接口只有一個 doInTransaction 方法的聲明。該方法也就是前面的 TransactionTemplate 模板類中的“回調(diào)”方法(或 者是“鉤子”方法) 。 【例 11-35 】 TransactionCallback 接口的定義的代碼示例 package org.springframework.t

24、ransaction.support; import org.springframework.transaction.TransactionStatus; public interface TransactionCallback Object doInTransaction(TransactionStatus status); 4、“控制反轉(zhuǎn)”和“依賴倒置”的不同點(diǎn) 雖然 “依賴倒置” 和“控制反轉(zhuǎn)” 在設(shè)計(jì)層面上都是消解模塊耦合的有效方法， 也都是試圖令具體的、 易變的模塊依賴于抽象的、穩(wěn)定的模塊的基本原則，但二者在使用語境和關(guān)注點(diǎn)上存在差異。 ( 1)“倒置”的目標(biāo)不同 “依賴倒置”強(qiáng)調(diào)的

25、是對于傳統(tǒng)的、源于面向過程設(shè)計(jì)思想的層次概念的“倒置” ，而“控制反轉(zhuǎn)” 強(qiáng)調(diào)的是對程序流程控制權(quán)的反轉(zhuǎn)； ( 2)應(yīng)用的范圍不同 “依賴倒置”的使用范圍更為寬泛，既可用于對程序流程的描述(如流程的主從和層次關(guān)系) ，也可 用于描述其他擁有概念層次的設(shè)計(jì)模型(如服務(wù)組件與客戶組件、核心模塊與外圍應(yīng)用等)。 而“控制反轉(zhuǎn)”則僅適用于描述流程控制權(quán)的場合(如算法流程或業(yè)務(wù)流程的控制權(quán))。 我們也可以把“控制反轉(zhuǎn)”看作是“依賴倒置”的一個特例。例如，用模板方法模式實(shí)現(xiàn)的“控制反 轉(zhuǎn)”機(jī)制其實(shí)就是在框架系統(tǒng)和應(yīng)用系統(tǒng)之間抽象出了一個描述所有算法步驟原型的接口類，框架系統(tǒng)依 賴于該接口類定義并實(shí)現(xiàn)程序流程，而應(yīng)用系統(tǒng)依賴于該接口類提供具體算法步驟的實(shí)現(xiàn)，應(yīng)用系統(tǒng)對框 架系統(tǒng)的依