高内聚低耦合簡單學習

起因：子產品獨立性指每個子產品隻完成系統要求的獨立子功能，并且與其他子產品的聯系最少且接口簡單，

兩個定性的度量标準――耦合性和内聚性。

    耦合性也稱塊間聯系。指軟體系統結構中各子產品間互相聯系緊密程度的一種度量。子產品之間聯系越

緊密，其耦合性就越強，子產品的獨立性則越差。子產品間耦合高低取決于子產品間接口的複雜性、調用的方

式及傳遞的資訊。

    耦合性分類(低――高): 無直接耦合;資料耦合;标記耦合;控制耦合;公共耦合;内容耦合;

1 無直接耦合:

2 資料耦合: 指兩個子產品之間有調用關系，傳遞的是簡單的資料值，相當于進階語言的值傳遞;

3 标記耦合: 指兩個子產品之間傳遞的是資料結構，如進階語言中的數組名、記錄名、檔案名等這些名字即标記，其實傳遞的是這個資料結構的位址;

4 控制耦合: 指一個子產品調用另一個子產品時，傳遞的是控制變量（如開關、标志等），被調子產品通過該控制變量的值有選擇地執行塊内某一功能;

5 公共耦合: 指通過一個公共資料環境互相作用的那些子產品間的耦合。公共耦合的複雜程式随耦合子產品的個數增加而增加。

6 内容耦合: 這是最高程度的耦合，也是最差的耦合。當一個子產品直接使用另一個子產品的内部資料，或通過非正常入口而轉入另一個子產品内部。

    内聚性又稱塊内聯系。指子產品的功能強度的度量，即一個子產品内部各個元素彼此結合的緊密程度的

度量。若一個子產品内各元素（語名之間、程式段之間）聯系的越緊密，則它的内聚性就越高。

    内聚性匪類(低――高): 偶然内聚;邏輯内聚;時間内聚;通信内聚;順序内聚;功能内聚;

1 偶然内聚: 指一個子產品内的各處理元素之間沒有任何聯系。

2 邏輯内聚: 指子產品内執行幾個邏輯上相似的功能，通過參數确定該子產品完成哪一個功能。

3 時間内聚: 把需要同時執行的動作組合在一起形成的子產品為時間内聚子產品。

4 通信内聚: 指子產品内所有處理元素都在同一個資料結構上操作（有時稱之為資訊内聚），或者指各處理使用相同的輸入資料或者産生相同的輸出資料。

5 順序内聚: 指一個子產品中各個處理元素都密切相關于同一功能且必須順序執行，前一功能元素輸出就是下一功能元素的輸入。

6 功能内聚: 這是最強的内聚，指子產品内所有元素共同完成一個功能，缺一不可。與其他子產品的耦合是最弱的。

    耦合性與内聚性是子產品獨立性的兩個定性标準，将軟體系統劃分子產品時，盡量做到高内聚低耦合，提高子產品的獨立性，為設計高品質的軟體結構奠定基礎。

    有個例子很容易明白：一個程式有50個函數，這個程式執行得非常好；然而一旦你修改其中一個函

數，其他49個函數都需要做修改，這就是高耦合的後果。

一旦你了解了它，你編寫概要設計的時候設計類或者子產品自然會考慮到“高内聚，低耦合”。

耦合指的子產品之間的關系，最弱的耦合設計是通過一個主要子產品來協調n個模

塊之間的運作。還是舉一個我舉過的例子：客戶要求在界面上增加一個字段，

你的項目要修改幾個地方呢？如果你隻要修改項目文檔，那麼你的開發構架就

是最低強度的耦合，而這種設計 成熟的開發團隊都已經做到了，他們使用開發

工具通過項目模型驅動資料庫和各層次的代碼，而不是直接修改那些代碼；

内聚指的是子產品内部的功能，最強的内聚就是功能單一到不能拆分，也就是原

子化，是以強内聚和弱耦合是相輔相成的，一個良好的設計是由若幹個強内聚

子產品以弱耦合的方式組裝起來的

1. 低耦合（Low Coupling）

“低耦合”這個詞相信大家已經耳熟能詳，我們在看spring的書籍、MVC的資料、設計模式的書籍，無處不提到“低耦合、高内聚”，它已經成為軟體設計品質的标準之一。那麼什麼是低耦合？

耦合就是對某元素與其它元素之間的連接配接、感覺和依賴的量度。這裡所說的元

素，即可以是功能、對象（類），也可以指系統、子系統、子產品。假如一個元

素A去連接配接元素B，或者通過自己的方法可以感覺B，或者當B不存在的時候就不

能正常工作，那麼就說元素A與元素B耦合。耦合帶來的問題是，當元素B發生變

更或不存在時，都将影響元素A的正常工作，影響系統的可維護性和易變更性。

同時元素A隻能工作于元素B存在的環境中，這也降低了元素A的可複用性。正因

為耦合的種種弊端，我們在軟體設計的時候努力追求“低耦合”。低耦合就是

要求在我們的軟體系統中，某元素不要過度依賴于其它元素。請注意這裡

的“過度”二字。系統中低耦合不能過度，比如說我們設計一個類可以不與JDK

耦合，這可能嗎？除非你不是設計的Java程式。再比如我設計了一個類，它不

與我的系統中的任何類發生耦合。如果有這樣一個類，那麼它必然是低内聚

（關于内聚的問題我随後讨論）。耦合與内聚常常是一個沖突的兩個方面。最

佳的方案就是尋找一個合适的中間點。

目前已經有大量的架構幫助我們降低我們系統的耦合度。比如，使用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，如何執行的操作，與我無關。

下載下傳文檔