有關“高內聚 低耦合”的疑問

        在軟體開發過程中經常會見到“高內聚 低耦合”，以前讀書的時候沒什麼在意，包括寫代碼從格式，到代碼的複用，到更進階的內聚耦合考慮的都很不周到。在工作後參與開發後，才感覺到代碼品質非常重要，對於我個人來說更是。對於內聚耦合的理解並不是很理解。查了一些資料，如下：

 

///////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

        內聚： 故名思議，表示內部間聚集、關聯的長度，那麼高內聚就是指要高度的聚集和關聯。
       而耦合其實就是指外部間的聯絡程度。
      在程式設定中高內聚就是要程式模組內、類內要保持高度的聯絡，也就是屬性間、方法間、屬性方法間要高度緊密、不能脫離聯絡。要麼方法中應該存在某些屬性的參數，要麼屬性中要返回方法的結果，這樣能夠充分調用代碼，減少代碼的冗餘。而耦合是指程式各個模組間要盡量保持距離，不能關聯的太近，即使是“父親與 兒子 ”（父類與子類），以及其它的擴充類，就好比是俗話中所講的：“親戚遠了香，近了臭” 道理一樣，關係過於親密，暴露的缺點（心眼）也就越容易被人看到（呵呵，比喻有點遠了   ），也就越容易產生矛盾；因此在程式設定中，類與類之間雖然存在繼承的關係，但是繼承的越多，那麼子類和父類也就越像，父類變了，子類也就需要變更；我想誰也不想剛剛設計完畢的代碼，隨著一個類的更改去大動工程吧！ 
    
       網路中也有很多關於“高內聚 低耦合”的文章，大家可以去瀏覽一下，這樣您會體會的更加深刻，說多了也是紙上談兵，不如大家在實際的開發中仔細體會！
       下面是網路中講的不錯的文章，供大家參考！

（1）http://www.1000sun.com/blog/user1/eluo/archives/2006/1432.html

這是判斷設計好壞的標準，主要是面向OO的設計，主要是看類的內聚性是否高，偶合度是否低。
高內聚:類與類之間的關係而定，高，意思是他們之間的關係要簡單，明了，不要有很強的關係，不然，運行起來就會出問題。一個類的運行影響到其他的類。

    低偶合：類內部的方法而言。把程式的功能盡量分散，別在一個類裡唯寫一個或很好的方法，因為那樣會給你的調試等帶來很多問題。出了錯你都不知道在什麼地方。

    系統的各個模組儘可能具有較大的獨立性，換句話說，希望這樣設計軟體結構，使得每個模組完成一個相對獨立的特定子功能，並且和其他模組之間的關係很簡單，以便能方便地把不同場合下寫成的程式模組組合成軟體系統。衡量模組獨立性的定性標準是內聚（一個模組內各個元素彼此結合的緊密程度）和耦合（一個軟體結構內不同模組之間互連程度的度量）。高內聚、低耦合的模組是設計時追求的目標。

直接影響:

如果程式在實現上沒有把低耦合,高內聚作為其設計要求,那麼你對程式功能上進行修改的時候,你要使用編輯器修改分散在各個源檔案中的代碼,再做編譯與串連;由於處理多個源檔案,很有可能,你不會一下子全部修改正確,你的改動還有可能導致新的錯誤,這樣你還必須尋找原因,浪費了時間。我想OO之所以引入類的封裝機制,也是實現低耦合,高內聚的一種手段.Java中在內之外還有package，更好一層,高階C++有namespace，都是為了這個目的。

對於軟體維護人員:

對於軟體維護來說,修改這樣的無序代碼無疑是一個噩夢,倘若代碼維護者與原作者非同一人,他要理解代碼實現的機制將要花費多大的精力,花幾天時間查看幾萬行代碼是對人的一種折磨,這僅是為了弄清楚幾個月前那些程式員是如何?xxx功能的,當然如果有相應的設計文檔與注釋,壓力會減輕一點。我就經曆過這種痛苦。但我想如果在源頭進行控制,在各個階段對方案評審會最大程度的避免出現諸如"一個功能實現分散在各個源檔案"的情況。這又回到一個永恒的主題,如何將風險控制在早期而不是事後討論。

（2）http://tieba.baidu.com/f?kz=434621288
“高內聚，低耦合”主要是闡述的物件導向系統中，各個類需要職責分離的思想。   
  每一個類完成特定的獨立的功能，這個就是高內聚。耦合就是類之間的互相調用關係，如果耦合很強，互相牽扯調用很多，那麼會牽一髮而動全身，不利於維護和擴充。   

類之間的設定應該要低耦合,但是每個類應該要高內聚.耦合是類之間相互依賴的尺度.如果每個對象都有引用其它所有的對象,那麼就有高耦合,這是不合乎要求的,因為在兩個對象之間,潛在性地流動了太多資訊.低耦合是合乎要求的:它意味著對象彼此之間更獨立的工作.低耦合最小化了修改一個類而導致也要修改其它類的"連鎖反應". 內聚是一個類中變數與方法串連強度的尺度.高內聚是值得要的,因為它意味著類可以更好地執行一項工作.低內聚是不好的,因為它表明類中的元素之間很少相關.成分之間相互有關聯的模組是合乎要求的.每個方法也應該高內聚.大多數的方法只執行一個功能.不要在方法中添加'額外'的指令,這樣會導致方法執行更多的函數. 
    
  推廣開來說，這個思想並不限於類與類之間的關係。模組和模組，子系統之間也都要遵守這個原則，才可以設計出延展性比較強的系統。

/////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 

 

 

一.關聯
對象之間互動的一種引用方式，關聯的強弱不同分為一般關聯（association），彙總（aggreagtion）和組合（composition）
在代碼實現上，一般關聯是通過方法應用另一個類。
public class Person{
private Computer computer;
public void setComputer(Computer computer){//在方法裡引用
this.computer=computer;
}

}
彙總是在當前類的建構函式裡引用另外一個類的功能
public class Person{
private Computer computer;
public Person(Computer computer){//在建構函式裡引用，資料是共用的
this.computer=computer;
}

}
組合是在該類的建構函式裡構造另外一個類
public class Person{
private Computer computer;
public Person(){
this.computer=neｗComputer();
/*在構造器內構造另一個類的執行個體.資料 computer是獨佔的,生命週期和 Person類執行個體一致
**/
}

}
概念上講,彙總和組合都是比較強的關聯，表達的都是整體與部分的關聯關係，相對於普通的屬性要強（屬性分特徵屬性和關聯屬性，特徵屬性又分普通屬性和推導屬性什麼是推導屬性？如果有一個屬性是birthday那麼age就是推導屬性，方便使用效能開銷低），組合和彙總的區別在例子總也有了體現。另外，組合關聯在資料庫中級連刪除。
與關聯相似的一個概念是依賴， 依賴是所有關係中最脆弱的，不是作為屬性存在，而是作為局部變數 如：class A{
void m(){
B
}
}意思是說只有用到方法m（）的時候才與B發生關係，所以有一種偶然性。
依賴是單向的（------>），關聯可以單向和雙向(-)
關聯只限於類和類對象和對象之間，依賴還可以表達組件之間，包之間，模組之間調用關係。
二.內聚
度量一個類獨立完成某項工作的能力。
三.耦合
度量系統內或系統之間依賴關係的複雜性。類之間的依賴關係的複雜度。
設計原則：高內聚低耦合