這是軟體工程中的概念
首先要知道乙個軟體是由多個子程式組裝而成,
而乙個程式由多個模組(方法)構成!
而內聚就是指程式內的各個模組之間的關係緊密程度,
偶合就是各個外部程式(子程式)之間的關係緊密程度.
所以很易明白,為什麼要高內聚?模組之間的關係越緊密,出錯就越少!低偶合?子程式間的關係越複雜,就會產生更多的意想不到的錯誤!會給以後的維護工作帶來很多麻煩!
理解：減少耦合首先要從判斷什麼是耦合開始，這個問題我們不會有太多的分歧。
我們都應該明白耦合不是不可避免的，所以完全的去耦合根本就不可能。而實際上任何的應用在現實中，以及在我的認識中都受到其他因素的影響。這也使我們的設計實際上根本就不可能完全的達到去耦合。於是我們可以從職責的細分開始，也就是讓職責可以在乙個合適的粒度上，這樣這個粒度的職責就總是被呼叫，而不是去呼叫別人然後又被呼叫這樣的互相緊密關聯。
同時我們也要注意到去耦合根本就不只是乙個存在於物件導向領域的特殊概念，而是在任何的方式下都存在的問題。我也要注意到去耦合所要解決的問題是更好的面對變更，或者說是更好的可以被擴充套件。忘記這兩點，單純的**去耦合是沒有意義的。也就是說我們要認識到，如果你的程式需求完全的確定，不需要考慮變更，你為區耦合作出的努力根本就沒有價值。而且去耦往往還意味著，對於執行效能的降低。而實際上去耦的同時往往可能會帶來新的潛在的耦合。實際上這裡還是要落實到你的程式段落的職責是不適很明確的問題。
而耦合會帶來系統的關聯鈍化，讓你很難確認你的關注點。這其實也帶來了你去耦的難度。而這實際上還是你的系統職責不清稀帶來的去耦隱患。你要做的還是明確各個部分的職責。
而說到最後，實際上情況非常簡單，就是你明確你的系統的職責。這可以用單一職責規則來得到保障，也就是你的程式中乙個要素變化的原因，就只能是乙個，乙個改變只能帶來乙個直接的結果。任何的去藕無非就是在這個原則下就職責和職責的原因以及後果進行細分和組織。
關於軟體工程 高內聚低耦合的原則
軟體設計中通常用耦合度和內聚度作為衡量模組獨立程度的標準。劃分摸塊的乙個準則就是高內聚低耦合。耦合度是指模組之間聯絡的緊密程度。模組間的耦合度是指模組之間的依賴關係，包括控制關係 呼叫關係 資料傳遞關係。模組間聯絡越多，其耦合性越強，同時表明其獨立性越差。降低模組間的耦合度能減少模組間的影響，防止對...
高內聚,低耦合
大家都在說高內聚，低耦合。問題是什麼是高內聚？什麼是低耦合？那它們的作用是什麼？先來談談什麼是耦合，耦合就是不同模組之間粘稠的程度。耦合度高證明你的模組之間粘稠，不好剝離模組功能。造成後續修改難度加大，所謂 動一發而牽全身 當你的 粘稠在一起的時候，就代表你的 需要重寫了。那麼避免這些個事情的發生，...
高內聚，低耦合
內聚，更為專業的說法叫功能內聚，是對軟體系統中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那麼該元素就具有高內聚性，反之則為低內聚性。其實結合oop的思想，高內聚應該是更加趨向於介面化，工廠模式可以很容易體現這種思想。即方法呼叫，只要通過相應的...