使用IoC與DI(Dependency Injection)有何意義? (一) 它到底是甚麼?

其實我們在好幾年前,就已經談過DI(Dependency Injection)這個主題。當時這類議題被視為進階的開發概念,但如果你最近開始使用 .net core,大概已經發現DI如今已變成.net core中的基本要求。

事實上,從事教育訓練這麼多年的觀察下來,不難發現其實還是有相當多的開發人員不真的很明白,到底DI對於軟體開發有何意義? 它能帶來什麼價值?

這一篇希望能夠用一個較為具體的實例,對初學者解釋到底什麼是DI,以及它能帶來的效益。

結論

先說結論,對開發人員來說,使用DI能夠帶來 提高可測試性(testability) 以及 提高可擴充性的價值,同時降低相依性,讓程式碼便於維護。

在 asp.net core當中DI如今已是基本方案,asp.net core 是以服務(DI Services)的形式把DI這個機制實現在框架當中。讓開發人員不管是用 razor page, MVC, 或是其他開發方式,都可以(幾乎是必須)採用DI服務。

我們很久以前就說過,『框架』本身其實就是一種限制、一種引導,誘導開發人員往某一種方向去開發程式。而如今 asp.net core 把DI納作框架的一部分,就是在引導開發人員在開發時走向某一個路線。

什麼路線呢? 就是高可測試性、低耦合以及高可擴充性,如果兩相比較,我覺得asp.net core中的DI可以為開發人員實現高可測試性這個目的的可能性大概會更高一些,估計是因為最近幾年,unit test已經成為開發領域的某種潮流。

什麼是物件相依性

但不管如何,.net core已經把DI視為基礎,而你要理解這一切,得先搞清楚什麼是物件的相依性。

我常在上架構設計課程時說,職責分離這個設計概念很容易理解,誰都知道不同職責的模塊或物件就該分離,問題是怎麼決定誰的職責是甚麼? 到底誰又該跟誰分離? 等到有一天你真的開始設計,就會發現理解是一回事,真的明白到能夠動手設計又是另一回事…

看個例子,我們先來了解一下背景需求。

假設,我們打算為企業建構一個薪資計算的功能,已知薪資計算會依據三個參數,分別是本月上班時數(WorkHours),時薪(HourlyWage),以及請假時數(PrivateDayOffHours)。

也就是說,倘若Eric本月上班 19天,每天8小時,時薪200,本月請假1天,每請假一天倒扣200元,則Eric的薪資為:

Eric薪資= (19x8) x 200 – (1 x 8) x 200 = 30400 – 1600 = $28800

為了實現這個功能,我們的設計了底下這樣的console程式,它包含一個主程式和兩個類別,我們先看類別的部分:

我們來談談上面這兩個類別的職責,為什麼計算薪資該分成兩個類別? 為何不寫成一個? 如果把上面SalaryFormula中計算薪資的Execute Method直接融入SalaryCalculator裡面作為內建的程式碼(Calculate的一部分),不是讓程式碼簡單的多了嗎? (其實,一般初學者肯定會這麼寫)

的確,但關鍵就在『需求』

由於考量到這是一個套裝軟體,將來會賣到不同的企業,每一個企業計算薪資的具體公式可能不同,我們希望未來計算薪資的公式可以隨時動態『抽換』,最理想的狀況是,賣給不同的企業,可以抽換成不同的模組。

請記得,最終職責的決定其實往往取決於『需求』。

因此,之所以把計算薪資設計成兩個類別,就是考量到上面這樣的背景需求。我們區分成兩個類別,一個是計算薪資的SalaryCalculator類別,另一個則是薪資計算公式SalaryFormula類別。

SalaryFormula是薪資計算的公式,它具體決定了薪資怎麼計算。而SalaryCalculator這個類別則是負責『計算』這個動作,但不管具體算法為何。

這兩個類別設計好了之後,我們再來看主程式如下:

你會發現主程式裡面new了一個SalaryCalculator類別來計算薪資,並且傳入SalaryFormula()物件實體作為參數。好了,現在問題來了。這整段程式碼有什麼缺點?

沒錯,從原始需求的角度來看,薪資計算的公式若想要可以動態調整,依照先前SalaryCalculator.cs的程式碼,由於類別SalaryCalculator會倚賴SalaryFormula類別的實作(SalaryCalculator.cs 16行相依於36行的SalaryFormula類別的具體實作,因為傳入的參數型別寫死了是SalaryFormula類別),未來這套軟體賣給了另一家公司,倘若想要改變薪資計算的公式,勢必得翻出原始程式碼(48行)來改寫SalaryFormula的實作才行。

砍斷針對具體實作的相依

好,知道問題在哪之後,我們來看怎麼調整? 其實很簡單,請回想起你熟悉的物件導向程式設計中的介面(interface)。請注意最大的改變在11,16,36,55行:

上面這段是修改後的類別,你會發現最大的差異在於55-59行增加了一個介面ISalaryFormula,該介面是類別SalaryFormula的抽象定義,而類別SalaryFormula(36-50)行則是ISalaryFormula的實作。

另外一個重要的修改是16行的SalaryCalculator(…)方法,傳入的物件的型別從SalaryFormula改為ISalaryFormula,如此一來,未來只要是符合ISalaryFormula介面所實作的類別,都可以當作參數傳入。

這一個修改動作,就在改變SalaryCalculator類別對於SalaryFormula類別的相依性,從原先針對類別實作的相依,改為對介面(抽象)相依。這樣做有什麼好處? 砍斷對具體實作的相依性,才能夠為將來系統能夠動態抽換計算公式而鋪路…我們接著往下看。

做了這樣的修改之後,未來倘若我們希望改變薪資的具體計算方式,我們無須修改整套程式碼,只需要再建構一個新的薪資計算類別,然後修改主程式即可(你如果一直往後看,未來只需要透過config檔案『設定』,連主程式都無須修改):

注意上面的程式碼當中,主程式有兩段6-9行與12-16行,本質上這兩段code幾乎完全一樣,唯一的差別是new SalaryCalculator(…)類別時傳入建構子的參數有所不同,一個是計算員工的公式類別實作,一個是計算老闆的公式類別實作。

你會發現由於老闆請假不扣薪(26行),因此即便參數完全一樣,但計算出的結果有所不同:

到這邊,我們已經為了動態抽換鋪好了基礎(對,這部分只是基礎,稱為IoC),接著我們來看,如何在ASP.NET Core中透過DI Services實現動態抽換。

如果你需要完整程式碼,請參考我的Github:
https://github.com/isdaviddong/DotNetCoreConsoleExample_IoC

-----------------------------

本文內容來自於『團隊開發與架構設計實務』課程,我們最近要開課囉,依照過去經驗這門課幾乎都是秒殺,如果你需要預先保留席次,請點選這裡登記唷。

若您要詢問問題,或是需要即時取得更多相關訊息,可按這裡加入FB專頁。
若這篇文章對您有所幫助,請幫我們分享出去,謝謝您的支持。

留言

這個網誌中的熱門文章

精彩(且驚人)的Semantic Kernel入門範例

使用Semantic Kernel 建立自然語言請假系統

在 LINE Bot 開發中使用Semantic Kernel建立自然語言請假系統

專業的價值...

使用CLI指令快速開啟Windows Terminal