為什么依賴注入對于程序員來說是件好事？
本文轉載自公眾號“讀芯術”(ID：AI_Discovery)。
為什么依賴注入對于程序員來說是件好事?本文將用Kotlin編寫示例說明這一問題的，但其中并未使用該特殊語法功能，因此每位程序員都能理解。
如果咖啡機不在咖啡館應該怎么辦?如果有一個空白空間，每次想喝咖啡時，就必須從頭開始構造機器。軟件中的運行速度要比在現實中快一百萬倍，因此可以合理編寫如下代碼：
- classProgrammer {
- funtakeBreak() {
- //constructing anew coffee machine:
- val coffeeMachine =EspressoCoffeeMachine()
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
但問題是，使用空的構造函數實際上并不能構造咖啡機。雖然結構性能也許不算一個因素，但使用咖啡機時所涉及的結構復雜性一定包含在內：
- 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)
- }
- }
你能從代碼中看出程序員在休息時做了什么嗎?
僅僅因為無法構建咖啡機，程序員就不喝咖啡而return(返回)工作嗎?在喝咖啡前，程序員怎么可能與所有providers(供應商)交談呢?這些都是可憐的programmer(程序員)的擔憂，他們只想喝到咖啡。
可以把它們都轉移到另一個用于構造咖啡機的類中，實際上，這就是工廠設計模式(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)
- }
- }
如你所見，工廠延遲了構造復雜性，但并未使其消失。
圖源：unsplash
在現實生活中，建造工具和使用工具是兩個完全分離的過程。人類一直在利用這一點，史前人類打磨好矛槍后才準備刺殺猛犸象。
程序員不需要在休息時忙著構造咖啡機。他們當然不需要從工廠帶來一個新機器，咖啡機只是程序員用來快速制作咖啡的工具罷了，這樣就能回到自己真正的工作中：寫代碼!
那么，依賴注入與這些有什么關系呢?
依賴注入是一種將類的構造代碼與其使用過程進行系統化分離的體系結構方法。方法有幾種，構造依賴倒置(constructiondependencies inversion)就是其中之一。
它意味著CoffeeMachine(咖啡機)的構造與使用咖啡機的Programmer(程序員)不應該緊密耦合。相反，Programmer(程序員)的構造直觀上應該依賴于CoffeeMachine(咖啡機)。
- classProgrammer/*constructor*/(
- //class member automatically assigned bythe constructor
- privateval coffeeMachine:CoffeeMachine
- ) {
- funtakeBreak() {
- coffeeMachine.pourCoffee()
- .into(coffeeCup)
- .awaitCompletion()
- drink(coffeeCup)
- }
- }
但是，這不是僅僅把咖啡機的構造轉移到容納程序員的類中嗎?
不一定。舉個例子，一家SoftwareCompanyX(軟件公司X)希望招到一名Programmer(程序員)：再次按照依賴倒置原則，使SoftwareCompanyX的構造依賴于Programmer即可，而不是將Programmer的構造與SoftwareCompanyX緊密耦合。
- classSoftwareCompanyX/*constructor*/(
- //class member automatically assigned bythe constructor
- privateval programmer:Programmer
- ) : /*implements*/SoftwareCompany {
- overridefunstartWorkingDay() {
- programmer.takeBreak()
- }
- }
如此一來，Programmer(程序員)可以輕易轉移到另一家SoftwareCompany(軟件公司)，休閑地喝一杯咖啡。她所需要的只是能為她提供 CoffeeMachine(咖啡機)參考的人，然后她就可以回來工作了。
最終，必須有人來進行構造。這個人將是唯一需要處理特定類群的構造細節的人，這也是他的唯一任務。構成的根源就是大多數依賴注入框架中的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()
- }
- }
所以，為什么需要依賴注入框架呢?
以下問題需要得到解答：
- 誰應該將模塊實例化?
- 如果一個模塊依賴于其他模塊該怎么辦?
- 怎么在不同地方共享同一對象實例?
- 單元測試怎么樣?
圖源：unsplash
依賴注入框架有助于應對這些挑戰，這樣就能專注于自己所在領域的挑戰，而不用從頭開始設計。咖啡時間結束了，希望你能學到一些新知識。
