前兩天，在物件導向設計原則—SOLID、從被動變主動—依賴反轉這兩篇文章中，我們聊完 SOLID，接下來幾天的主題，原本預計來談談單元測試，在準備寫文章時，突然發現筆者忘記提到低耦合、高內聚這個很重要的觀念。囧
所以，今天我們來聊聊為什麼開發程式時，符合低耦合、高內聚的原則有什好處？
簡單來說，就是兩個模組間的關連性或相依性。
當兩模組間的相依性越高，那它們的耦合性越高，稱之為高耦合。反之，則謂之為耦合。
在高耦合的情況下，很容易發生一種情況。明明只是一個很小的需求異動，但是連帶影響到跟它有相依關係的部份。造成修改一小塊程式碼，導至很多地方都出錯，要花額外時間去修正被影響的程式碼。
最常見的情況就是資料與商業邏輯的高耦合，或是UI與商業邏輯的高耦合。
簡單來說，就是模組本身不需依賴其他模組，就能完成工作。
當模組的內聚力越高，表示模組包含的物件或功能就越多。雖然提高了模組本身的獨立性，減少跟其他模組的耦合性，但也可能造成重覆程式碼，或違背單一職責原則的情況發生。
高內聚、低耦合的目的，就是為了提升各模組功能的重用性、擴展性、維護性。
講白一點，就是為了達到盡可能不影響現有功能的前提下，完成需求異動的修改的目標。
內聚力與耦合性就像天平的兩端，一邊增加，另一邊就必定減少。要如何取得兩者之間的水平，就非常考驗工程師本身的系統規劃與設計能力。
持續優化程式碼的要點之一，就是在每一次的開發中，程式都要盡可能的符合高內聚、低耦合。這可以有效減少，發生的需求變動時，所需變動修改的工作量。
如果軟體工程師沒有特別自我要求，又為了快速開發的目標，極有可能造成高耦合、低內聚這種，充滿壞味道的程式碼。如果軟體交付出去，就不需要維護跟修改，那當然沒有什麼影響。
但是……
在軟體業，這樣的情況不能說沒有，但少至又少。大部份的情況，可能會要求變動部份功能，來應付另一個客戶的需求。
看倌們想像一下，有一支軟體當初為了快，造成程式碼中，UI、資料與商業邏輯的程式充滿了高耦合、低內聚的壞味道。而這支軟體，又因為客戶需求些微不同，分成了四、五個版本。
我們先假設，這支軟體原本的資料來源是 txt, 但好死不死，一年後，老闆指示這支軟體，所有出貨的版本，要求能同時支援 csv 的資料來源。
保證負責維護修改該軟體的工程師，會改到想吐血。這是因為高耦合、低內聚的程式，往往修改程式是牽一髮而動全身。而且無法直接替換模組，變成改完一個版本後，相同的事情可能要再重覆做。
IT閱讀, java多聚合，少繼承，低耦合，高內聚
關於文章中，模塊粒度的說明，筆者覺得非常值得看看。
iT邦幫忙, 中鳥階段-高內聚，低耦合。
iThome鐵人賽
看影片追技術