coupling, 即兩個東西之間的一種連接，使他們彼此關聯。
以前大學裏學軟件工程和麪向對象的時候，就時常聽到解耦和低耦合，所以現在在做開發的時候，也往往會去想，怎麼降低耦合度呢。
軟件工程書籍中，這麼寫道，高內聚及低耦合可以給我們軟件開發人員帶來可讀性、複用性、可維護性和易變更性。
耦合天成
軟件開發過程中，耦合是不可避免的，除非做出來一個超級巨大，包含一切功能的類/模塊，都放在裏面做（這顯然並不是高內聚，只是把亂七八糟的揉在一起），否則模塊與模塊之間必然存在一定的耦合。
既然耦合不可避免，那高耦合和低耦合，又會對開發和維護產生什麼影響呢？
高耦合，也就意味着兩者之間存在強的關聯，比如強持有、雙向依賴、多個變量/常量的互相訪問，如此也就造成其中一個需要更改的時候，另一個類也需要大量更改，而在Runtime的領域，則可能發生其中一個導致另一個不能釋放。尤其實際生產過程中，往往不只是兩個類有耦合關係，會有更多的類，從而產生一條耦合鏈。
低耦合，即兩者之間關聯較弱，比如廣播，dataflow架構，單向單依賴等等。組合優於繼承這個說法，也是從業務模型的角度，組合有時候相對於繼承降低了耦合。
耦合的代價
高耦合的代價，從開發人員角度來說，會導致
- 維護困難：因爲各種邏輯揉在一起，互相之間依賴來依賴去，查問題的時候很難定位。
- 變更困難：由於關聯太強，修改一個小需求卻要改很多邏輯
- 難以複用：新開發的功能用到了相同的邏輯，但是隻能複製黏貼過去。比較常見的一個例子就是應該在utils裏的東西卻在業務代碼裏。
- 可讀性差：過一陣子自己看，或者換了負責人員後，很難讀懂原來的邏輯
低耦合的代價，則可能會需要付出性能、代碼行數、更多的時間去設計和解耦。