為什么依賴注入對于程序員來說是件好事？
本文轉(zhuǎn)載自公眾號“讀芯術(shù)”(ID：AI_Discovery)。
為什么依賴注入對于程序員來說是件好事?本文將用Kotlin編寫示例說明這一問題的，但其中并未使用該特殊語法功能，因此每位程序員都能理解。
如果咖啡機不在咖啡館應(yīng)該怎么辦?如果有一個空白空間，每次想喝咖啡時，就必須從頭開始構(gòu)造機器。軟件中的運行速度要比在現(xiàn)實中快一百萬倍，因此可以合理編寫如下代碼：
- classProgrammer {
- funtakeBreak() {
- //constructing anew coffee machine:
- val coffeeMachine =EspressoCoffeeMachine()
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
但問題是，使用空的構(gòu)造函數(shù)實際上并不能構(gòu)造咖啡機。雖然結(jié)構(gòu)性能也許不算一個因素，但使用咖啡機時所涉及的結(jié)構(gòu)復雜性一定包含在內(nèi)：
- classProgrammer {
- funtakeBreak() {
- val waterTank =waterTankProvider.getWaterTank()
- if (waterTank ==null) {
- //TODO: handlefailed to provide water tank.
- return
- }
- val beansContainer =beansContainerProvider.getBeansContainer()
- if (beansContainer ==null) {
- //TODO: handlefailed to provide beans container.
- return
- }
- val milkContainer =milkContainerProvider.getMilkContainer()
- if (milkContainer ==null) {
- //TODO: handlefailed to provide milk container
- return
- }
- val milkPump =milkPumpProvider.getMilkPump()
- if (milkPump ==null) {
- //TODO: handlefailed to provide milk pump
- return
- }
- //constructing anew coffee machine:
- val coffeeMachine =EspressoCoffeeMachine(
- waterTank,
- beansContainer,
- milkContainer,
- milkPump,
- )
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
你能從代碼中看出程序員在休息時做了什么嗎?
僅僅因為無法構(gòu)建咖啡機，程序員就不喝咖啡而return(返回)工作嗎?在喝咖啡前，程序員怎么可能與所有providers(供應(yīng)商)交談呢?這些都是可憐的programmer(程序員)的擔憂，他們只想喝到咖啡。
可以把它們都轉(zhuǎn)移到另一個用于構(gòu)造咖啡機的類中，實際上，這就是工廠設(shè)計模式(Factorydesign pattern)。
- classProgrammer {
- funtakeBreak() {
- //Constructs new CoffeeMachineFactory
- val coffeeMachineFactory =CoffeeMachineFactory()
- val coffeeMachine =coffeeMachineFactory.create()
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
它清潔了代碼，但這遲早會不得不再次改變。程序員們被寵壞了：我們喜歡嘗試來自不同工廠、不同機器所制造的咖啡。
- classProgrammer {
- funtakeBreak() {
- val brand =brandProvider.getBrand()
- if (brand ==null) {
- //TODO: handlefailed to provide brand
- return
- }
- valcoffeeMachineFactory =coffeeMachineFactoryProducer.produceFactoryBy(brand)
- if (coffeeMachineFactory ==null) {
- //TODO: handlefailed to provide CoffeeMachineFactory
- return;
- }
- val machineModel =coffeeMachineModelProvider.getMachineModel()
- if (machineModel ==null) {
- //TODO: handle failed to provideCoffeeMachineModel
- return;
- }
- val coffeeMachine = coffeeMachineFactory.create(machineModel)
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
如你所見，工廠延遲了構(gòu)造復雜性，但并未使其消失。
圖源：unsplash
在現(xiàn)實生活中，建造工具和使用工具是兩個完全分離的過程。人類一直在利用這一點，史前人類打磨好矛槍后才準備刺殺猛犸象。
程序員不需要在休息時忙著構(gòu)造咖啡機。他們當然不需要從工廠帶來一個新機器，咖啡機只是程序員用來快速制作咖啡的工具罷了，這樣就能回到自己真正的工作中：寫代碼!
那么，依賴注入與這些有什么關(guān)系呢?
依賴注入是一種將類的構(gòu)造代碼與其使用過程進行系統(tǒng)化分離的體系結(jié)構(gòu)方法。方法有幾種，構(gòu)造依賴倒置(constructiondependencies inversion)就是其中之一。
它意味著CoffeeMachine(咖啡機)的構(gòu)造與使用咖啡機的Programmer(程序員)不應(yīng)該緊密耦合。相反，Programmer(程序員)的構(gòu)造直觀上應(yīng)該依賴于CoffeeMachine(咖啡機)。
- classProgrammer/*constructor*/(
- //class member automatically assigned bythe constructor
- privateval coffeeMachine:CoffeeMachine
- ) {
- funtakeBreak() {
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
但是，這不是僅僅把咖啡機的構(gòu)造轉(zhuǎn)移到容納程序員的類中嗎?
不一定。舉個例子，一家SoftwareCompanyX(軟件公司X)希望招到一名Programmer(程序員)：再次按照依賴倒置原則，使SoftwareCompanyX的構(gòu)造依賴于Programmer即可，而不是將Programmer的構(gòu)造與SoftwareCompanyX緊密耦合。
- classSoftwareCompanyX/*constructor*/(
- //class member automatically assigned bythe constructor
- privateval programmer:Programmer
- ) : /*implements*/SoftwareCompany {
- overridefunstartWorkingDay() {
- programmer.takeBreak()
- }
- }
如此一來，Programmer(程序員)可以輕易轉(zhuǎn)移到另一家SoftwareCompany(軟件公司)，休閑地喝一杯咖啡。她所需要的只是能為她提供 CoffeeMachine(咖啡機)參考的人，然后她就可以回來工作了。
最終，必須有人來進行構(gòu)造。這個人將是唯一需要處理特定類群的構(gòu)造細節(jié)的人，這也是他的唯一任務(wù)。構(gòu)成的根源就是大多數(shù)依賴注入框架中的Module(模塊)。
- classSoftwareCompanyModule {
- funprovideSoftwareCompany():SoftwareCompany {
- returnSoftwareCompanyX(provideProgrammer())
- }
- privatefunprovideProgrammer():Programmer {
- returnAndroidDeveloper(provideCoffeeMachine(provideFactory()))
- }
- privatefunprovideCoffeeMachine(factory:CoffeeMachineFactory):CoffeeMachine {
- returnfactory.create(provideMachineModel())
- }
- privatefunprovideMachineModel():String {
- returnBuildConfig.COFFEE_MACHINE_MODEL
- }
- privatefunprovideFactory():CoffeeMachineFactory {
- returnCoffeeMachineFactory(provideCoffeeMachineBrand())
- }
- privatefunprovideCoffeeMachineBrand():String {
- returnBuildConfig.COFFEE_MACHINE_BRAND
- }
- }
所以，SoftwareCompanyModule (軟件公司模塊)負責連接一切，并只對外公開SoftwareCompany(軟件公司)。
- classSiliconValley {
- privateval softwareCompany:SoftwareCompany
- init {
- softwareCompany =softwareCompanyModule.provideSoftwareCompany()
- }
- funonDayStart() {
- softwareCompany.startWorkingDay()
- }
- }
所以，為什么需要依賴注入框架呢?
以下問題需要得到解答：
- 誰應(yīng)該將模塊實例化?
- 如果一個模塊依賴于其他模塊該怎么辦?
- 怎么在不同地方共享同一對象實例?
- 單元測試怎么樣?
圖源：unsplash
依賴注入框架有助于應(yīng)對這些挑戰(zhàn)，這樣就能專注于自己所在領(lǐng)域的挑戰(zhàn)，而不用從頭開始設(shè)計?？Х葧r間結(jié)束了，希望你能學到一些新知識。
