設計原則入門：依賴反轉原則 Dependency Inversion Principle

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