在軟體設計中,常常會遇到這樣的情況:你要改動某個小功能,結果卻發現得改動好幾個不相關的部分,感覺像牽一髮動全身。這時候你可能會懷疑設計是不是出了問題,這種情況往往是類別之間依賴關係過於緊密,導致系統變得難以維護。這就是為什麼我們需要「依賴反轉原則」來解決這種問題。 什麼是依賴反轉原則? 依賴反轉原則強調:「高層模組不應該依賴於低層模組,兩者都應依賴於抽象(介面或抽象類別)」。設計時我們應該把具體的細節抽象化,讓不同模組之間不再直接依賴彼此的實作,而是依賴一個共同的介面或抽象類別,這樣系統會更加靈活、易於擴充和維護。 打個比方,就是「不要讓大腦直接指揮手腳運動,而是透過神經傳導」。同樣地,程式中的核心邏輯不應該直接依賴具體的實作細節,而應該透過一層抽象來進行溝通,這樣無論實作有任何變更,對核心邏輯的影響都會降到最低。 舉個簡單的例子 想像你正在建造一棟房子,假如水電系統的每一條線路都直接連接在開關上,那麼每次你想換個燈泡,就可能要重新拉線,整個系統變得非常麻煩。如果你有一個控制面板,可以透過這個面板來控制不同的電路,那麼無論你想怎麼改變燈光系統,控制面板的設計都不會受影響。 依賴反轉原則就是這個控制面板,它將具體的細節隔離開來,讓我們在修改或擴展功能時不需要大動干戈,這讓整個系統變得更加穩定、可擴展。 為什麼這麼做? 當你遵循依賴反轉原則後,系統變得更有彈性,維護性大幅提高。即使底層的實作細節有所改變,也不會影響到高層邏輯。假如你有一個支付系統,最初只支援信用卡,但後來你想加入 PayPal,或者其他支付方式,只要實作符合的介面即可,而不需要改動核心訂單處理邏輯。 這種設計方式的優點顯而易見:它讓系統更加靈活和可擴展,特別適合大型系統或快速變動的需求。不過,缺點是可能會增加設計的複雜度,尤其是對小型專案來說,過度抽象可能會帶來不必要的開發負擔。 總結一下,遵守依賴反轉原則可以讓系統更具彈性,當底層實作發生變動時,不需要修改高層邏輯,這樣維護和擴展系統的時候就更方便,讓我們在開發複雜應用時更加得心應手。 如果你對設計原則有興趣,可以看看我今年在iThome鐵人賽分享的實例文章。 https://ithelp.ithome.com.tw/articles/10356664