軟體裡面的耦合性是指各個模組配合起來完成一個可交付的功能時，這些模組相互之間的依賴程度，或者說需要它們互相配合的這種需要的強烈程度。我可以舉個簡單的例子，因為我最近也常用這個例子。比如你的客戶或領導要你做個軟體，為他提供一個蘋果和一個梨子。那你可能很自然就會覺得要把這個軟體劃分為兩個模組，一個提供一個蘋果，另一個提供一個梨子。如果你這麼做，這兩個模組可以說就是低耦合甚至無耦合的。因為你這種做法實際上是把可交付成果進一步分解為兩個小的可交付成果。所以這兩個模組在“配合起來完成一個最小的可交付成果”這件事情上，對它們互相的配合的需要就是沒有，雖然它們仍然要配合起來完成最終的可交付成果，但是毫無疑問的是，對這種配合的需求沒有隨著模組的劃分的深入而增加。但是你也可能採用另外的劃分方式。比如你還是決定劃分為兩個模組，一個用來提供上半個蘋果和上半個梨子，一個用來提供下半個蘋果和下半個梨子。這種劃分方式可能是違反直覺的。但是他確實是一種可以存在的劃分方式，而且可以有它的理由。比如你發現蘋果和梨子的上半部分都是黃的，下半部分都是綠的，那麼你這種方式就可能便於你為它們統一著色。每個模組進行著色時不用換畫筆的顏色了。但是採用這種劃分方式，由於你的客戶並不可能接受什麼半個蘋果和梨子的交付物，所以你的兩個模組必須配合起來，要同時完成工作才能提供一個交付物。而且它們還要常常顧及對方的感受，比如第一個模組它提供的上半個蘋果的直徑就要跟第二個模組提供的下半個蘋果的直徑一致才行。梨子那邊也是一樣。所以它們必須在更多方面配合好才能完成一個可交付成果。也就是耦合度更高。那你可以知道後面這種方法會有幾個問題，首先是違反直覺，不易理解，其次修改一個模組就要同時修改另一個模組。這些都導致在客戶變更需求的時候，或者你自己需要修改它的時候，更容易陷入混亂。所以才會提倡低耦合。