耦合度的概念
耦合度是對模塊(類)間關聯程度的度量，可以用"聯系"作同義詞，"獨立性"作反義詞。
耦合度分類(由高到低)
(1)內容耦合。當一個模塊直接修改或操作另一個模塊的數據,或者直接轉入另一個模塊時，就發生了內容耦合。此時，被修改的模塊完全依賴於修改它的模塊。類與類之間直接調用或繼承關系都是屬於這種耦合。
需完全避免內容耦合，重點在於不要在類內部直接操作另一個類的對象的數據成員，可以通過在操作類中增加一個函數接口向客戶類提供服務來實現
(2)公共耦合。兩個及兩個以上的模塊共同引用一個全局數據項就稱為公共耦合。
(3)控制耦合。一個模塊在界面上傳遞一個信號（如開關值、標志量等）控制另一個模塊，接收信號的模塊的動作根據信號值進行調整，稱為控制耦合。
(4)標記耦合。模塊間通過參數傳遞復雜的內部數據結構，稱為標記耦合。此數據結構的變化將使相關的模塊發生變化。
(5)數據耦合。模塊間通過參數傳遞基本類型的數據，稱為數據耦合。
(6)非直接耦合。模塊間沒有信息傳遞時，屬於非直接耦合。
1. 低耦合（Low Coupling）
“低耦合”這個詞相信大家已經耳熟能詳，我們在看spring的書籍、MVC的數據、設計模 式的書籍，無處不提到“低耦合、高內聚”，它已經成為軟件設計質量的標准之一。那么什么是低耦合？耦合就是對某元素與其它元素之間的連接、感知和依賴的量 度。這里所說的元素，即可以是功能、對象（類），也可以指系統、子系統、模塊。假如一個元素A去連接元素B，或者通過自己的方法可以感知B，或者當B不存 在的時候就不能正常工作，那么就說元素A與元素B耦合。耦合帶來的問題是，當元素B發生變更或不存在時，都將影響元素A的正常工作，影響系統的可維護性和 易變更性。同時元素A只能工作於元素B存在的環境中，這也降低了元素A的可復用性。正因為耦合的種種弊端，我們在軟件設計的時候努力追求“低耦合”。低耦 合就是要求在我們的軟件系統中，某元素不要過度依賴於其它元素。請注意這里的“過度”二字。系統中低耦合不能過度，比如說我們設計一個類可以不與JDK耦 合，這可能嗎？除非你不是設計的Java程序。再比如我設計了一個類，它不與我的系統中的任何類發生耦合。如果有這樣一個類，那么它必然是低內聚（關於內 聚的問題我隨后討論）。耦合與內聚常常是一個矛盾的兩個方面。最佳的方案就是尋找一個合適的中間點。
哪些是耦合呢？
1．元素B是元素A的屬性，或者元素A引用了元素B的實例（這包括元素A調用的某個方法，其參數中包含元素B）。
2．元素A調用了元素B的方法。
3．元素A直接或間接成為元素B的子類。
4．元素A是接口B的實現。
幸運的是，目前已經有大量的框架幫助我們降低我們系統的耦合度。比如，使用struts我們 可以應用MVC模型，使頁面展現與業務邏輯分離，做到了頁面展現與業務邏輯的低耦合。當我們的頁面展現需要變更時，我們只需要修改我們的頁面，而不影響我 們的業務邏輯；同樣，我們的業務邏輯需要變更的時候，我們只需要修改我們的java程序，與我們的頁面無關。使用spring我們運用IoC（反向控 制），降低了業務邏輯中各個類的相互依賴。假如類A因為需要功能F而調用類B，在通常的情況下類A需要引用類B，因而類A就依賴於類B了，也就是說當類B 不存在的時候類A就無法使用了。使用了IoC，類A調用的僅僅是實現了功能F的接口的某個類，這個類可能是類B，也可能是另一個類C，由spring的配 置文件來決定。這樣，類A就不再依賴於類B了，耦合度降低，重用性提高了。使用hibernate則是使我們的業務邏輯與數據持久化分離，也就是與將數據 存儲到數據庫的操作分離。我們在業務邏輯中只需要將數據放到值對象中，然后交給hibernate，或者從hibernate那里得到值對象。至於用 Oracle、MySQL還是SQL Server，如何執行的操作，與我無關。
但是，作為優秀的開發人員，僅僅依靠框架提供的降低軟件耦合的方法是遠遠不夠的。根據我的經驗，以下一些問題我們應當引起注意：
1） 根據可能的變化設計軟件
我們采用職責驅動設計，設計中盡力做到“低耦合、高內聚”的一個非常重要的前提是，我們的軟 件是在不斷變化的。如果沒有變化我們當然就不用這么費勁了；但是如果有變化，我們希望通過以上的設計，使我們在適應或者更改這樣的變化的時候，付出更小的 代價。這里提供了一個非常重要的信息是，我們努力降低耦合的是那些可能發生變更的地方，因為降低耦合是有代價的，是以增加資源耗費和代碼復雜度為代價的。 如果系統中某些元素不太可能變更，或者降低耦合所付出的代價太大，我們當然就應當選擇耦合。有一次我試圖將我的表現層不依賴於struts，但發現這樣的 嘗試代價太大而失去意義了。對於軟件可能變更的部分，我們應當努力去降低耦合，這就給我們提出一個要求是，在軟件設計的時候可以預判日后的變化。根據以往 的經驗我認為，一個軟件的業務邏輯和采用的技術框架往往是容易變化的2個方面。客戶需求變更是我們軟件設計必須考慮的問題。在RUP的開發過程中，為什么 需要將分析設計的過程分為分析模型和設計模型，愚以為，從分析模型到設計模型的過程實際上是系統從滿足直接的客戶需求到優化系統結構、適應可預見的客戶需 求變更的一個過程。這種客戶需求的變更不僅僅指對一個客戶需求的變更，更是指我們的軟件從適應一個客戶需求到適應更多客戶需求的過程。另一個方面，現在技 術變更之快，EJB、hibernate、spring、ajax，一個一個的技術像走馬燈一樣從我們腦海中滑過，我們真不知道明天我在用什么。在這樣的 情況下，適應變化就是我們最佳的選擇。
2） 合理的職責划分
合理的職責划分，讓系統中的對象各司其職，不僅是提高內聚的要求，同時也可以有效地降低耦 合。比如評審計划BUS、評審表BUS、評審報告BUS都需要通過評審計划DAO去查詢一些評審計划的數據，如果它們都去直接調用評審計划DAO（如圖 A），則評審計划BUS、評審表BUS、評審報告BUS三個對象都與評審計划DAO耦合，評審計划DAO一旦變更將與這三個對象都有關。在這個實例中，實 際上評審計划BUS是信息專家（關於信息專家模式我將在后面討論），評審表BUS和評審報告BUS如果需要獲得評審計划的數據，應當向評審計划BUS提出 需求，由評審計划BUS提供數據（如圖B）。經過這樣的調整，系統的耦合度就降低了。
3） 使用接口而不是繼承
通過對耦合的分析，我們不難發現，繼承就是一種耦合。如果子類A繼承了父類B，不論是直接或 間接的繼承，子類A都必將依賴父類B。子類A必須使用在存在父類B的環境中，父類B不存在子類A就不能使用，這樣將影響子類A的可移植性。一旦父類B發生 任何變更，更改或去掉一個函數名，或者改變一個函數的參數，都將導致子類A不得不變更，甚至重寫。假如父類B的子類數十上百個，甚至貫穿這個項目各個模 塊，這樣的變更是災難性的。這種情況最典型的例子是我們現在使用hibernate和spring設計DAO對象的方式，具體的描述參見我寫的《如何在 struts + spring + hibernate的框架下構建低耦合高內聚的軟件結構》一文。