高內聚松耦合在程式設計中如何做到

內聚：一個模組內各個元素彼此結合的緊密程度

耦合：一個軟體結構內不同模組之間互連程度的度量

我們一直追求著，高內聚，低耦合。

對於低耦合的理解是：

一個完整的系統，模組與模組之間，儘可能的使其獨立存在。

也就是說，讓每個模組，儘可能的獨立完成某個特定的子功能。

模組與模組之間的介面，盡量的少而簡單。

如果某兩個模組間的關係比較複雜的話，最好首先考慮進一步的模組劃分。

這樣有利於修改和組合。

對於低耦合的理解是：

在一個模組內，讓每個元素之間都儘可能的緊密相連。

也就是充分利用每一個元素的功能，各施所能，以最終實現某個功能。

如果某個元素與該模組的關係比較疏鬆的話，可能該模組的結構還不夠完善，或者是該元素是多餘的。

    內聚和耦合，包含了橫向和縱向的關係。功能內聚和資料耦合，是我們需要達成的目標。橫向的內聚和耦合，通常體現在系統的各個模組、類之間的關係，而縱向的耦合，體現在系統的各個層次之間的關係。

對於我在編碼中的困惑，我是這樣想的，用物件導向的思想去考慮一個類的封裝。

一個方法，如何封裝，拿到現實生活中來看，看這種能力（方法）是否是屬於這類事物（類）的本能。

如果是，就封裝在這個類裡。

如果不是，則考慮封裝在其它類裡。

如果這種能力，很多事物都具有，則一定要封裝在這類事物的總類裡。

如果這種能力，很多事物都會經常用到，則可以封裝成一個總類的靜態方法。

　　人們不易實現松耦合，因為，孤獨的模組毫無意義，只有模組間的相互協調地工作，才能實現系統的目的。而對於模組間的相互關係的設計，沒有一定的經驗是難以把握。耦合的強度依賴於：(1)一個模組對另一個模組的調用;(2)一個模組向另一個模組傳遞的資料量;(3)一個模組施加到另一個模組的控制的多少;(4)模組之間介面的複雜程度。等等。

　　當然，“強內聚、松耦合”也是有矛盾的，如：內聚性越強，則要求的函數越多(每個函數只作一件“事”)，這樣，將它們組合成“大”的功能，也就越複雜，就不可能達到松耦合。因此，應在二者之間作出平衡與折衷的選擇，這也體現程式員的水平。從系統論的角度來看，系統是有層次的，即系統可以分為子系統，模組可分為子模組，“強內聚、松耦合”的“度”的把握，應結合系統的次層性來考慮，即通常應在層次性上作出折衷，如：模組內子程式(下一個層次上)應共用資料(有一定的耦合度)，而減少全域變數能降低子程式性間的耦合性。

　　物件導向的語言進一步強化了“強內聚、松耦合”，類的封裝性既強調了相關內容(資料及其操作)的內聚，又強調了類的獨立性和私密性。而類的繼承性以及友元等，就是在松耦合的原則下規範了類之間的關聯關係。類與類之間通常通過介面的契約實現服務提供者/服務要求者模式，這就是典型的松耦合。

　　“強內聚、松耦合”對於程式編寫分工、程式的可維護性以及測試都有重要的關係，如：從設計角度來看，在“強內聚、松耦合”的指導下進行的設計得到的程式模組，符合專案管理的WBS(分工結構圖)的要求，其相對獨立的模組可以分配到具體的程式員進行開發，另外，程式編碼外包也必須建立在這種原則的設計之下;從程式生命期角度來看，它有利於提高程式品質，特別是方便於程式的日後維護，即程式模組的相對獨立性是可維護性的保證;再從測試角度來看，符合“強內聚、松耦合”的程式，易於對局部(模組)進行黑箱測試，也易於編寫測試用的“樁”和“驅動”。

　　“強內聚、松耦合”也是對組織圖的要求，項目組分為幾個小組(正式的或非正式的)，各小組的工作應是高度相關的，各小組之間的工作應盡量是較少相關或有明確的介面，從而減少溝通成本。其實，“強內聚、松耦合”是系統中應遵守的普遍原則，我們在許多領域都可以找到它的應用。高內聚的模組,互相之間依賴性比較少，某個模組一但出現問題的時候，能把錯誤控制在一個模組內．不會因為一個模組出了問題,而影響了其他功能模組．保證了其他功能的完整性，不會影響使用者的其他動作，能讓給使用者帶來的麻煩降低到最低限度．程式員也能快速的定位出問題所在的模組，進行問題修改．模組之間沒有太多的牽連，更便於程式員的問題修改．在問題修改後，也不會給其他功能模組帶來太多的影響．測試人員在做單元或整合測試的時候，能夠更容易把裡面的程式模組之間的邏輯理清楚，能設計出高覆蓋率的用例把程式碼後模組介面都能完全覆蓋測試到．也能讓測試人員在做迴歸測試時，降低一定的風險．

耦合性高的模組，相互之間依賴性比較多，模組與模組之間的關係也比較複雜．就容易出現,一個程式模組出現了問題,導致其他功能模組都不能正常運行.而且由於關係的複雜性，給程式員定位及修改問題帶來一定的不便．也影響了使用者的所有操作，給使用者帶來更大損失．而且由於模組之間的複雜關係，即便程式員修改了一個問題後，也不能保證不會帶來更多的缺陷．給測試人員做單元和整合測試帶來了太多的不便．需要花大量的時間去理清內部的邏輯．在這樣的情況下，可能也會給測試工作帶來遺漏的地方，留下隱患．測試人員也要花更多的時間進行迴歸測試，來保證系統程式符合規定要求了．無形中給項目帶來了更多的風險．

所以，在寫大系統時盡量提高程式的內聚，降低程式的耦合程式。緊耦合意味著函數功能複雜並傳遞參數較多，將複雜功能的函數分解成功能獨立的模組以實現：高內聚，松耦合。