說說依賴注入
在面向?qū)ο缶幊讨校覀兘?jīng)常處理處理的問題就是解耦，程序的耦合性越低表明這個程序的可讀性以及可維護(hù)性越高。控制反轉(zhuǎn)(Inversion of Control或IoC)就是常用的面向?qū)ο缶幊痰脑O(shè)計原則，使用這個原則我們可以降低耦合性。其中依賴注入是控制反轉(zhuǎn)最常用的實現(xiàn)。
什么是依賴
依賴是程序中常見的現(xiàn)象，比如類Car中用到了GasEnergy類的實例energy，通常的做法就是在Car類中顯式地創(chuàng)建GasEnergy類的實例，并賦值給energy。如下面的代碼
|
1
2
3
4
5
6
7
8
9
10
11
|
interface Energy { } class GasEnergy implements Energy { } class Car { Energy energy = new GasEnergy();} |
存在問題
類Car承擔(dān)了多余的責(zé)任，負(fù)責(zé)energy對象的創(chuàng)建，這必然存在了嚴(yán)重的耦合性。舉一個現(xiàn)實中的例子，一輛汽車使用哪種能源不是由汽車來決定，而是由汽車制造商（CarMaker）來決定，這是汽車制造商的責(zé)任。
可擴展性，假設(shè)我們想修改能源為電動力，那么我們必然要修改Car這個類，明顯不符合開放閉合原則。
不利于單元測試。
依賴注入
依賴注入是這樣的一種行為，在類Car中不主動創(chuàng)建GasEnergy的對象，而是通過外部傳入GasEnergy對象形式來設(shè)置依賴。 常用的依賴注入有如下三種方式
構(gòu)造器注入
將需要的依賴作為構(gòu)造方法的參數(shù)傳遞完成依賴注入。
|
1
2
3
4
5
6
|
class Car { Energy mEnergy; public Car(Energy energy) { mEnergy = energy; }} |
Setter方法注入
增加setter方法，參數(shù)為需要注入的依賴亦可完成依賴注入。
|
1
2
3
4
5
6
7
|
class Car { Energy mEnergy; public void setEnergy(Energy energy) { mEnergy = energy; }} |
接口注入
接口注入，聞其名不言而喻，就是為依賴注入創(chuàng)建一套接口，依賴作為參數(shù)傳入，通過調(diào)用統(tǒng)一的接口完成對具體實現(xiàn)的依賴注入。
|
1
2
3
4
5
6
7
8
9
10
11
|
interface EnergyConsumerInterface { public void setEnergy(Energy energy);} class Car implements EnergyConsumerInterface { Energy mEnergy; public void setEnergy(Energy energy) { mEnergy = energy; }} |
接口注入和setter方法注入類似，不同的是接口注入使用了統(tǒng)一的方法來完成注入，而setter方法注入的方法名稱相對比較隨意。
框架取舍
依賴注入有很多框架，最有名的就是Guice，當(dāng)然Spring也支持依賴注入。Guice采用的是運行時讀取注解，通過反射的形式生成依賴并進(jìn)行注入。這種形式不太適合Android移動設(shè)備，畢竟這些操作都在運行時處理，對性能要求較高。
Dagger則是Android開發(fā)適合的依賴注入庫，其同樣采用類注解的形式，不同的是它是在編譯時生成輔助類，等到在運行時使用生成的輔助類完成依賴注入。
用還是不用
其實注入框架用還是不用，是一個問題，如若使用框架，則要求團隊每一個人都要遵守說明來編寫代碼解決依賴注入。而這些框架其實也并非很容易就能上手，學(xué)習(xí)系數(shù)相對復(fù)雜，難以掌握，這也是需要考慮的問題。
個人觀點為不推薦也不反對使用這些框架，但是覺得有些時候我們寄希望于一個框架，不如平時注意這些問題，人為避免何嘗不是對自己的一種基本要求呢？
依賴查找
依賴查找和依賴注入一樣屬于控制反轉(zhuǎn)原則的具體實現(xiàn)，不同于依賴注入的被動接受，依賴查找這是主動請求，在需要的時候通過調(diào)用框架提供的方法來獲取對象，獲取時需要提供相關(guān)的配置文件路徑、key等信息來確定獲取對象的狀態(tài)。
以上就是對依賴注入的資料詳細(xì)介紹，后續(xù)繼續(xù)補充相關(guān)資料，謝謝大家對本站的支持！
