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

閱讀時間約 2 分鐘

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

    6會員
    83內容數
    對於經營自媒體、部落格或社群媒體感興趣?我專注於提供實用的寫作技巧、數位行銷策略,以及個人成長建議。 每週,我會分享提升寫作技巧、優化部落格經營、有效管理社群媒體、以及投資理財的寶貴知識。追蹤我,獲得實用的工具和建議,讓你的個人品牌和財務管理更上一層樓!
    留言0
    查看全部
    發表第一個留言支持創作者!
    ShengYu的沙龍 的其他內容
    想像你在設計一個系統,而這個系統裡有一個超級大的介面,裡面包含了所有功能。結果每次你只想加一個小功能,卻必須修改這個巨大介面,還要實作你根本不需要的其他功能,這不僅浪費時間,還讓整個系統越來越複雜。 這時候就輪到「介面隔離原則」出場了!這個原則的意思是:「不要強迫一個類別去實作它不需要的功能」
    你有沒有遇到過這種情況:當你在開發過程中,使用了子類別替換父類別,結果卻發現程式變得不正常了?這很可能是你違反了「里氏替換原則 (Liskov Substitution Principle, LSP)」。LSP 是物件導向設計中的一個重要原則,能確保我們使用繼承時不會破壞程式的穩定性。 什麼是
    你有沒有遇過這樣的情況?當你設計一個系統時,一開始覺得一切順利,結果過了不久,客戶突然要求增加新功能。問題來了,每次改需求,你的程式碼都變得一團混亂,越改越多錯誤,最後讓你崩潰了。 軟體開發中需求變動是常態,但每次修改都得動到核心程式碼,難免會增加出錯的風險,也讓開發效率大打折扣。今天就要來聊聊「
    在寫程式的過程中,你是否遇過一個類別或模組負責了太多事情,結果導致程式變得難以維護?這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時,改動可能會牽一髮動全身影響其他部分,這時候「單一職責原則 (SRP)」便派上用場。 單一職責原則是什麼? 簡單來說,單一
    當你在開發應用程式時,可能會面臨要建立不同物件的需求。這時候簡單工廠模式(Simple Factory Pattern)是一個很實用的解決方案。今天我們就來用特斯拉汽車工廠的例子來解釋這個概念。 什麼是簡單工廠模式? 簡單工廠模式的核心思想是:將物件的建立過程封裝起來,客戶端(也就是使用者)只需要
    在學習設計模式時,可能會讓人感到困惑:「為什麼有這麼多種工廠模式?它們到底解決什麼問題?」工廠方法模式(Factory Method Pattern)提供了一種方式來建立單一物件,這個方法可以在子類中覆寫以產生不同的物件。而抽象工廠模式(Abstract Factory Pattern)在這個基礎上
    想像你在設計一個系統,而這個系統裡有一個超級大的介面,裡面包含了所有功能。結果每次你只想加一個小功能,卻必須修改這個巨大介面,還要實作你根本不需要的其他功能,這不僅浪費時間,還讓整個系統越來越複雜。 這時候就輪到「介面隔離原則」出場了!這個原則的意思是:「不要強迫一個類別去實作它不需要的功能」
    你有沒有遇到過這種情況:當你在開發過程中,使用了子類別替換父類別,結果卻發現程式變得不正常了?這很可能是你違反了「里氏替換原則 (Liskov Substitution Principle, LSP)」。LSP 是物件導向設計中的一個重要原則,能確保我們使用繼承時不會破壞程式的穩定性。 什麼是
    你有沒有遇過這樣的情況?當你設計一個系統時,一開始覺得一切順利,結果過了不久,客戶突然要求增加新功能。問題來了,每次改需求,你的程式碼都變得一團混亂,越改越多錯誤,最後讓你崩潰了。 軟體開發中需求變動是常態,但每次修改都得動到核心程式碼,難免會增加出錯的風險,也讓開發效率大打折扣。今天就要來聊聊「
    在寫程式的過程中,你是否遇過一個類別或模組負責了太多事情,結果導致程式變得難以維護?這類情況經常被稱為「巨石類別 (God Class)」。當我們對這樣的類別做出任何變更時,改動可能會牽一髮動全身影響其他部分,這時候「單一職責原則 (SRP)」便派上用場。 單一職責原則是什麼? 簡單來說,單一
    當你在開發應用程式時,可能會面臨要建立不同物件的需求。這時候簡單工廠模式(Simple Factory Pattern)是一個很實用的解決方案。今天我們就來用特斯拉汽車工廠的例子來解釋這個概念。 什麼是簡單工廠模式? 簡單工廠模式的核心思想是:將物件的建立過程封裝起來,客戶端(也就是使用者)只需要
    在學習設計模式時,可能會讓人感到困惑:「為什麼有這麼多種工廠模式?它們到底解決什麼問題?」工廠方法模式(Factory Method Pattern)提供了一種方式來建立單一物件,這個方法可以在子類中覆寫以產生不同的物件。而抽象工廠模式(Abstract Factory Pattern)在這個基礎上
    你可能也想看
    Google News 追蹤
    Thumbnail
    這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
    Thumbnail
    最近觀察到許多網站有一個特性,就是有些網站會使用不同的模板做同一個關鍵字。 很多開發者在做產品的時候會有一個特性,就是會使用相同的模板。使用相同模板的好處不外乎是減少重複開發的時間、快速上站。 因為其實在程式開發中有很多功能可能是相似甚至是重複的。在這種情況下我們不應該重複去開發相同功能,而
    Thumbnail
    本文介紹了在網站開發中如何運用狀態機的原則和設計方法。通過具體案例分析,以及狀態和數據的區分,詳細介紹了狀態機的設計原則和應用。讀者可以通過本文瞭解如何將狀態機應用於實際的網站開發中。
    Thumbnail
    本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
    ※ 工廠模式 定義: 工廠模式是一種實現了「工廠」概念的物件導向設計模式。它提供一個通用的工廠介面,將創建instance(實例)的程式碼交由子類別各自實現,並根據需求去動態地生成相應的物件。這種模式將物件的創建邏輯與使用邏輯分開,使程式碼更容易維護和擴展。 特點: 具有高度標準化和同質性的
    ※ 單例模式介紹 ※ 定義:單例模式是一種設計模式,確保一個class(類)只有一個實例,並提供一個存取它的全域存取點。無論如何取值,皆只對這個實例取值。 ※ 目的:保證一個類別只會產生一個物件,而且提供存取該物件的統一方法。 ※ 講解:單例模式確保一個類無論怎麼 new 或 get,都只能拿
    Thumbnail
    當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
    讓我在這篇文章總結一下前面對物件導向設計的討論,我們討論了物件導向的四個特性:繼承、抽象、多型、封裝,分析了它們的問題,並跟函數式編程的思維做比較。我們引入了與之相對應的特性:泛型、特性系統、模組化,有些特性雖然跟那四個特性很像,但在一些細微的地方有不同的詮釋,使得整體思考方式很不一樣。 「繼
    物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
    上一篇文章提到有些介面不應被繼承,但物件導向的子類別只能繼承父類別的介面,因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制,這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承,更適合使用組合,根本不需要使用繼承疊加特性。 資料類型的定義往往跟怎麼建構模型相
    類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的
    Thumbnail
    這個秋,Chill 嗨嗨!穿搭美美去賞楓,裝備款款去露營⋯⋯你的秋天怎麼過?秋日 To Do List 等你分享! 秋季全站徵文,我們準備了五個創作主題,參賽還有機會獲得「火烤兩用鍋」,一起來看看如何參加吧~
    Thumbnail
    最近觀察到許多網站有一個特性,就是有些網站會使用不同的模板做同一個關鍵字。 很多開發者在做產品的時候會有一個特性,就是會使用相同的模板。使用相同模板的好處不外乎是減少重複開發的時間、快速上站。 因為其實在程式開發中有很多功能可能是相似甚至是重複的。在這種情況下我們不應該重複去開發相同功能,而
    Thumbnail
    本文介紹了在網站開發中如何運用狀態機的原則和設計方法。通過具體案例分析,以及狀態和數據的區分,詳細介紹了狀態機的設計原則和應用。讀者可以通過本文瞭解如何將狀態機應用於實際的網站開發中。
    Thumbnail
    本章節的目的是介紹在TypeScript中如何進行例外處理。涵蓋了例外處理的重要性、語法、常見異常類型以及如何主動觸發異常訊息及用戶自定義異常訊息。為讀者提供了全面而深入的了解,以提高程式的可靠性、提供更好的反饋、增加程式的容錯性以及改善程式的可讀性。
    ※ 工廠模式 定義: 工廠模式是一種實現了「工廠」概念的物件導向設計模式。它提供一個通用的工廠介面,將創建instance(實例)的程式碼交由子類別各自實現,並根據需求去動態地生成相應的物件。這種模式將物件的創建邏輯與使用邏輯分開,使程式碼更容易維護和擴展。 特點: 具有高度標準化和同質性的
    ※ 單例模式介紹 ※ 定義:單例模式是一種設計模式,確保一個class(類)只有一個實例,並提供一個存取它的全域存取點。無論如何取值,皆只對這個實例取值。 ※ 目的:保證一個類別只會產生一個物件,而且提供存取該物件的統一方法。 ※ 講解:單例模式確保一個類無論怎麼 new 或 get,都只能拿
    Thumbnail
    當你在開發程式時,難免會遇到各種錯誤和異常情況。這些錯誤可能是因為代碼中的錯誤、外部資源無法訪問或其他不可預期的狀況。為了提高程式的可靠性、穩定性和可維護性,我們使用「例外處理」來處理這些異常情況。
    讓我在這篇文章總結一下前面對物件導向設計的討論,我們討論了物件導向的四個特性:繼承、抽象、多型、封裝,分析了它們的問題,並跟函數式編程的思維做比較。我們引入了與之相對應的特性:泛型、特性系統、模組化,有些特性雖然跟那四個特性很像,但在一些細微的地方有不同的詮釋,使得整體思考方式很不一樣。 「繼
    物件導向設計的一個重點就是封裝,這有很多層面上的意義,但基本上就是控制物件的成員變數和方法的存取權。物件導向的封裝還跟繼承機制有關,這使得有一些時候我們逼不得已必須把函式定義在類別上,這種做法使得物件的功能變得難以拆解。封裝應該是模組的職責,並不需要再給物件相同的能力。 一般的模組系統就是把相
    上一篇文章提到有些介面不應被繼承,但物件導向的子類別只能繼承父類別的介面,因而產生一些不合適的介面實作。trait/typeclass則沒有這種繼承機制,這似乎使需要繼承的特性無法直接使用。然而函數式導向比起繼承,更適合使用組合,根本不需要使用繼承疊加特性。 資料類型的定義往往跟怎麼建構模型相
    類似於trait/typeclass的特性系統能提供程式「延展性」,它能讓函式針對不同的類型做出不同的行為。這種機制與物件導向的繼承非常像,然而特性系統的彈性比較大一點,而且概念上也有一些差別。為了探討討論這些差異,我們必須深入了解繼承機制到底是什麼。 繼承並不是建立子類關係的唯一方法。所謂的