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 提供的方法，或訪問模塊B 中的某些

2、數(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)系一旦我們采用 “分而治之”的處理方法后， 模塊之間就必須以某種方式交換信息，也就是必然要 發(fā)

3、生某種耦合關(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)的API庫或者框架中的組件試圖令具體的、易變的模塊依賴于抽象的、穩(wěn)定的模塊的基本原則

4、。在 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ì)量造成很大的危害。特別是當(dāng)需求發(fā)生變化時，代碼的維護(hù)成本將非常高。所以，我們必須想盡辦法來控制和消解不必要

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

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

7、具體是磁盤還是鍵盤，那是下面的實(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)槔习傩諘淮饝?yīng)，也不能說實(shí)話，因?yàn)轭I(lǐng)導(dǎo)會對你有意見，兒子思索良久問：那我該說什么 ? 父親意味深長的說：空話笑話不但好笑，還能反映一定的道理，為啥空話這么有用，因?yàn)樗浅橄?/p>

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

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

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

11、有一定的技術(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)行優(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ù)庫的各種連接功能，兩者都只依賴于

12、數(shù)據(jù)連接組件的接口。請見下面的圖中所示的優(yōu)化設(shè)計(jì)結(jié)果的類圖。這樣， 數(shù)據(jù)訪問操作組件到數(shù)據(jù)連接組件的依賴關(guān)系被數(shù)據(jù)連接組件的接口所隔離開。 因?yàn)樵诮涌谥兄话怂枰母鞣N連接的服務(wù)功能的定義，而不包括任何連接的服務(wù)功能的具體實(shí)現(xiàn)，所以數(shù)據(jù)連接組件的接口的內(nèi)容在具體設(shè)計(jì)時也會很簡單。在數(shù)據(jù)連接組件接口不變的情況下，數(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)方案還存在一定的問題， 因

13、為數(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)椋?當(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)?Oracle10G 數(shù)據(jù)庫系統(tǒng)）時，此時也

14、將必然會影響到數(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)一步完善！下面的圖所示為這樣的應(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ù)庫訪問操作的抽象接口，

15、并為該數(shù)據(jù)庫訪問操作的抽象接口提供不同的具體數(shù)據(jù)庫訪問操作的實(shí)現(xiàn)類。這樣的設(shè)計(jì)能夠避免改動對數(shù)據(jù)庫訪問操作的使用類（一般為上層的業(yè)務(wù)層組件類）的代碼，下面的圖為進(jìn)一步完善后的設(shè)計(jì)結(jié)果的類圖。控制反轉(zhuǎn)(IocInversion of Control)1、消解框架和我們的應(yīng)用系統(tǒng)類之間的依賴關(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）面向

16、框架和面向系統(tǒng)類庫開發(fā)的不同點(diǎn)框架和類庫最重要的區(qū)別是：框架是一個半成品的應(yīng)用程序，而類庫只包含一系列可被應(yīng)用程序調(diào)用的類。類庫給用戶提供了一系列可復(fù)用的類，這些類的設(shè)計(jì)都符合面向?qū)ο笤瓌t和模式。用戶使用時，可以創(chuàng)建這些類的實(shí)例，或從這些類中繼承出新的派生類，然后調(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)系有以下特

17、點(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)通過“控制反轉(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)用。其目的主要是簡

18、化工作量，對于一些常見的業(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ā)時采用的手段）的替代物就是“模板方法模式”（ 一般是面向應(yīng)用框架開發(fā)時采用的手段）。2）什么是模板方法模式“模板方法模式”，也就是“好萊塢原則（不要調(diào)用我們，讓我們調(diào)用你） ”。模板方法模式是框架系統(tǒng)的基礎(chǔ)，任何框架系統(tǒng)都離不開模板方法模式如 Struts 框架中的插件技術(shù)implements PlugInpublic final class UserDatabasePlugInpublic v

19、oid destroy() publicvoid init(ActionServletservlet, ModuleConfig( 3) Spring 框架中的TransactionTemplate 模板類的代碼【例 11-34 】 TransactionTemplate 模板類的部分代碼示例 package org.springframework.transaction.support;/ import 語句，在此加以省略publicclassTransactionTemplateDefaultTransactionDefinition implements InitializingBean

20、public Object execute(TransactionCallbackaction) throwsTransactionExceptionif (this.transactionManager instanceofCallbackPreferringPlatformTransactionManager)return (CallbackPreferringPlatformTransactionManager)extendsconfig) throwsServletExceptionexecute(this, action);this.transactionManager).elseT

21、ransactionStatus status =this.transactionManager.getTransaction(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)

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

23、的代碼示例package org.springframework.transaction.support;import org.springframework.transaction.TransactionStatus; public interface TransactionCallbackObject 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)的是對于傳統(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)”看作