內聚，更為專業的說法叫功能內聚，是對軟體系統中元素職責相關性和集中度的度量。如果元素具有高度相關的職責，除了這些職責內的任務，沒有其它過多的工作，那麼該元素就具有高內聚性，反之則為低內聚性。
其實結合oop的思想，高內聚應該是更加趨向於介面化，工廠模式可以很容易體現這種思想。即方法呼叫，只要通過相應的介面，即可得到不同的實現。無需修改介面對應類的內容及實現方式。
舉例理解：
這就好像，如果我是乙個專案經理，我的職責是監控和協調我的專案各個階段的工作。當我的專案進入需求分析階段，我會請求需求分析員來完成；當我的專案 進入開發階段，我會請求軟體開發人員來完成；當我的專案需要測試的時候，我會請求測試人員。如果我參與了開發，我就不是乙個高內聚的元素，因為 開發不是我的職責。簡單說，各司其職
那麼高內聚的好處是什麼呢？
1.可讀性
如果一段程式條理非常清晰，每個類通過名稱或說明都能清楚明白它的意義，類的每個屬性、函式也都是易於理解 的它所應當完成的任務和行為，這段程式的可讀性必然提高。
2.復用性
在軟體開發中，最低等級的復用是**拷貝，然後是函式的復用、物件的復用、元件 的復用。**復用也使我們的**在復用的過程中不斷精化、不斷健壯、提高**質量。
3.可維護性和易變更性
高內聚的軟體，每個系統、模組、類的任務都高度相關，就使每一次的變更涉及的範圍縮小到最小。比如評審表發生了變更，只會 與評審表物件有關，我們不會去更改其它的物件。如果我們能做到這一點，我們的系統當然是可維護性好、易變更性好的系統。
低耦合是用來度量模組與模組直接的依賴關係。模組之間不要過度依賴其他模組
舉例：電器與插座之間是低耦合的關係，就算我替換了不同的插座，電器依然可以正常的工作。因此簡單的描述如下，就是a模組與b模組存在依賴關係，那麼當b發生改變時，a模組仍然可以正常工作，那麼就認為a與b是低耦合的。
比如現在的mvc模型，就將頁面和業務邏輯分離，如果需要改頁面，那麼業務邏輯不會有影響，如果需要修改業務邏輯，那麼頁面不會受到影響。
但是：
1. 低耦合是有一定代價的，因為低耦合是以增加資源消耗和**複雜度來實現的，所以我們努力降低耦合，只是在那些可能變更的地方。
2. 高內聚，低耦合本身就有一定的矛盾，我們只有把握住度，選擇恰當的方法
3. 高內聚有時候也不是說所有的情況都採用這樣的原則，當然高內聚還是要適度的，下面來舉例說明：例如內聚性要求強的話就像windows32中系統提供的api，裡面的函式太多了，都放在乙個dll中，那麼每個函式完成乙個功能。這樣強大的功能，會比較複雜，所以並不是完全的高內聚越高越好，還是要看實際的需要。
高內聚,低耦合
大家都在說高內聚，低耦合。問題是什麼是高內聚？什麼是低耦合？那它們的作用是什麼？先來談談什麼是耦合，耦合就是不同模組之間粘稠的程度。耦合度高證明你的模組之間粘稠，不好剝離模組功能。造成後續修改難度加大，所謂 動一發而牽全身 當你的 粘稠在一起的時候，就代表你的 需要重寫了。那麼避免這些個事情的發生，...
高內聚低耦合
明確一點，乙個程式如果是高內聚零耦合會是最完美的，但是沒有絕對的零耦合。也就不存在什麼完美的程式了。1 什麼是高內聚 低耦合？首先了解什麼是內聚 耦合 1.1.1內聚性 每乙個程式中可能會按照不同功能，將整個 段劃分為不同的模組，每乙個模組內部元素彼此之間會有某些聯絡，此種聯絡就是內聚性。同乙個模組...
高內聚 低耦合
高內聚 低耦合是軟體設計的普遍原則，但在實際的工作中，有時我們並不能清楚的認識到關於它們的兩個問題 1 為什麼要高內聚 低耦合。2 如何做到高內聚 低耦合。高內聚 低耦合這個概念出現的比較早，也是我們在接觸軟體設計時被告知的第一條原則。但很多人並不清楚，它能給我們帶來什麼實際的好處，在與有些同事們討...