iT邦幫忙

2018 iT 邦幫忙鐵人賽
DAY 11
3
Software Development

保持前進、持續優化程式碼內涵系列 第 11

11. 斷開鎖鏈! 低耦合、高內聚

前兩天,在物件導向設計原則—SOLID從被動變主動—依賴反轉這兩篇文章中,我們聊完 SOLID,接下來幾天的主題,原本預計來談談單元測試,在準備寫文章時,突然發現筆者忘記提到低耦合高內聚這個很重要的觀念。囧

所以,今天我們來聊聊為什麼開發程式時,符合低耦合高內聚的原則有什好處?

耦合(Coupling)

簡單來說,就是兩個模組間的關連性或相依性

當兩模組間的相依性越高,那它們的耦合性越高,稱之為高耦合。反之,則謂之為耦合。

在高耦合的情況下,很容易發生一種情況。明明只是一個很小的需求異動,但是連帶影響到跟它有相依關係的部份。造成修改一小塊程式碼,導至很多地方都出錯,要花額外時間去修正被影響的程式碼。

最常見的情況就是資料與商業邏輯的高耦合,或是UI與商業邏輯的高耦合。

內聚(Cohesion)

簡單來說,就是模組本身不需依賴其他模組,就能完成工作。

當模組的內聚力越高,表示模組包含的物件或功能就越多。雖然提高了模組本身的獨立性,減少跟其他模組的耦合性,但也可能造成重覆程式碼,或違背單一職責原則的情況發生。

小結

高內聚、低耦合的目的,就是為了提升各模組功能的重用性、擴展性、維護性
講白一點,就是為了達到盡可能不影響現有功能的前提下,完成需求異動的修改的目標。

內聚力耦合性就像天平的兩端,一邊增加,另一邊就必定減少。要如何取得兩者之間的水平,就非常考驗工程師本身的系統規劃與設計能力。

持續優化程式碼的要點之一,就是在每一次的開發中,程式都要盡可能的符合高內聚低耦合。這可以有效減少,發生的需求變動時,所需變動修改的工作量。

如果軟體工程師沒有特別自我要求,又為了快速開發的目標,極有可能造成高耦合、低內聚這種,充滿壞味道的程式碼。如果軟體交付出去,就不需要維護跟修改,那當然沒有什麼影響。

但是……

在軟體業,這樣的情況不能說沒有,但少至又少。大部份的情況,可能會要求變動部份功能,來應付另一個客戶的需求。

看倌們想像一下,有一支軟體當初為了快,造成程式碼中,UI、資料與商業邏輯的程式充滿了高耦合、低內聚的壞味道。而這支軟體,又因為客戶需求些微不同,分成了四、五個版本。

我們先假設,這支軟體原本的資料來源是 txt, 但好死不死,一年後,老闆指示這支軟體,所有出貨的版本,要求能同時支援 csv 的資料來源。

保證負責維護修改該軟體的工程師,會改到想吐血。這是因為高耦合、低內聚的程式,往往修改程式是牽一髮而動全身。而且無法直接替換模組,變成改完一個版本後,相同的事情可能要再重覆做。

推薦文章


上一篇
10. 從被動變主動—依賴反轉
下一篇
12. 談談單元測試 (待補完)
系列文
保持前進、持續優化程式碼內涵24
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言