原文：
http://socket.blog.163.com/blog/static/209873004201096210555/高內聚，低耦合(High Cohesion、Low Coupling)
是一句近乎于“為實現四個現代化而努力”式的口號，耳熟并不一定能詳。這個口號是在軟件工程里第一次碰到的，它的定義估計是計算專業術語里最欠扁的定義，內聚：一個模塊內各個元素彼此結合的緊密程序。耦合：一個軟件結構內不同模塊之間互連程序的度量。這兩個定義，相當地“形而上學”“不知所云”。這是軟件工程中判斷設計好壞的標準，主要是面向對象設計，主要是看類的內聚性是否高，偶合度是否低。為什么要高內聚，使模塊之間的關系越緊密出錯就趙少，越緊密運行效率越高！低耦合，就是說，子程序之間的關系越簡單，越容易擴展和維護，越復雜就會產生出更多的意想不到的錯誤！不利于維護。
程序員天生都是內聚的高手，違反高內聚的反而是那些有一定水平的程序員，可能是誤用了設計模式，可能是考慮問題過分全面，把一個功能單一的類分割成多個類。這里重點說低耦合，耦合就是類之間的互相調用關系，如果耦合很強，互相牽扯調用很多，那么會牽一發而動全身，不利于維護和擴展。什么方法、數據、不加分析地往一個類里整，甚至時一個類的所有數據成員設成public，方便在其它類里直接修改數據。生活中很多“低耦合”的例子，如床與床單，如果是緊耦合的話，換床單時，也要換床。再如桌子與抽屜。
圖中的上半部分中，把一個軟件模塊抽象成線條，軟件模塊互相依賴，這是一種面向過程的開發方式，如果軟件是不改變的，那么這種高耦合度的結構也無可厚非，有時象底層軟件如操作系統等，一切以執行效率優先，而且需求并不改變頻繁的情況下，是適用的。但在實際開發過程中，軟件需求的變化是導致這種模式被否定的真正原因。一旦有一個模塊改變，那么需要改動到其它好幾個模塊，而且更要命的時，被影響的模塊又會影響其它模塊，或者干脆又把影響力傳遞給當初最先改動的模塊。
下圖中的模塊結構通過梳理，使他們依附于一條粗線條，它是主邏輯模塊，是相對穩定的高層的、抽象的模塊。而其它通過一個小空心圓點（表示接口）與粗線條進行連接的小短線條代表次模塊，它被分成兩個部分，接口和實現接口的子類對象，它們通過接口與主邏輯模塊形成依賴。相對來說，次模塊變化較快，而主模塊變化較慢。剛才提到的生活例子中，床相對于床單來說是主要的，核心的，成本較高的，它的使用年限是10年，而床單使用年限是2年，就是說床的模塊變化速度慢于床單的變化速度，如果床2個月變一次，那么邏輯結構就混亂了。床為床單提供了一個尺寸接口，床單只要符合這個接口，就可以組合使用。那么這個接口就必須是相對穩定的。
設計模式做為軟件開發過程中一種創造性的總結思維，使軟件開發人員，在開發軟件產品時，有了更加明確的軟件解耦的思路，設計模式來源于生活，卻指導于軟件。事實上，短期來看，要求低耦合并沒有很明顯的好處，因為利用設計模式來解決問題是需要軟件開發的智力和時間成本的。況且引入了誤用設計模式的風險，所以短期內使用設計模式來解耦反而會影響系統的開發進度。低耦合的好處是長期回報的，體現在系統持續發展的過程中，系統具有更好的重用性，維護性，擴展性，持續的支持業務的發展，而不會成為業務發展的障礙。