本教程是轉載教程,目的是讓大家了解又一個(gè)很強大的依賴(lài)注入框架Guice.
Guice 是一個(gè)依賴(lài)項注入(DI)框架。幾年來(lái)我一直建議開(kāi)發(fā)人員使用 DI,因為它提高了可維護性、可測試性和靈活性。通過(guò)觀(guān)察工程師對 Guice 的反饋,我發(fā)現說(shuō)服程序員去采用一種新技術(shù)的最好方法是使這種技術(shù)簡(jiǎn)單易用。Guice 讓 DI 變得很簡(jiǎn)單,因此 Google 采用了這種方法。我希望本文能幫助您輕松學(xué)習 Guice。
Guice 2.0 beta
在寫(xiě)這篇文章時(shí),Guice 開(kāi)發(fā)團隊正在奮力編寫(xiě) Guice 2.0,希望能在 2008 年底之前發(fā)布。早期的 beta 發(fā)布在 Google 代碼下載站點(diǎn)。這是一個(gè)好消息,因為 Guice 團隊添加了一些新功能,使 Guice 代碼的使用和理解變得更簡(jiǎn)單。beta 版沒(méi)有最終版中的一些功能,但是 beta 很穩定,質(zhì)量也很好。事實(shí)上,Google 在產(chǎn)品軟件中使用的是 beta 版。我建議您使用 beta 版。這篇文章是專(zhuān)門(mén)為 Guice 2.0 編寫(xiě)的,介紹了 Guice 的一些新功能,但沒(méi)有討論 1.0 中已經(jīng)廢棄的一些功能。Guice 團隊向我保證:這里討論的功能在最終發(fā)行版和當前 beta 版中都是一樣的。
如果您已經(jīng)了解了 DI,而且知道為什么要借助一個(gè)框架來(lái)使用 DI,那么您可以跳到 通過(guò) Guice 進(jìn)行基本注入 小節。否則,請繼續閱讀,了解 DI 的好處。
DI 案例
我將以一個(gè)例子開(kāi)始。假設我正在編寫(xiě)一個(gè)超級英雄(superhero)應用程序,同時(shí)實(shí)現一個(gè)名為 Frog Man 的 hero(英雄)。清單 1 是相關(guān)代碼和第一個(gè)測試(您一定明白編寫(xiě)單元測試的重要性,這里就不多說(shuō)了)。
清單 1. 一個(gè)基本 hero 及其測試
- public class FrogMan {
- private FrogMobile vehicle = new FrogMobile();
- public FrogMan() {}
- // crime fighting logic goes here...
- }
- public class FrogManTest extends TestCase {
- public void testFrogManFightsCrime() {
- FrogMan hero = new FrogMan();
- hero.fightCrime();
- //make some assertions...
- }
- }
似乎一切正常,但在運行測試時(shí)出現了如清單 2 所示的異常:
清單 2. 依賴(lài)項出現問(wèn)題
- java.lang.RuntimeException: Refinery startup failure.
- at HeavyWaterRefinery.<init>(HeavyWaterRefinery.java:6)
- at FrogMobile.<init>(FrogMobile.java:5)
- at FrogMan.<init>(FrogMan.java:8)
- at FrogManTest.testFrogManFightsCrime(FrogManTest.java:10)
似乎 FrogMobile 構建了一個(gè) HeavyWaterRefinery,假設我不能在測試中構建其中一個(gè)依賴(lài)項。當然,我可以在生產(chǎn)環(huán)境中實(shí)現這一點(diǎn),但是不能保證能在測試中構建第二個(gè)提煉廠(chǎng)(refinery)。在現實(shí)生活中,您不可能提煉出氧化氘,但您可以依賴(lài)遠程服務(wù)器和強大的數據庫。原理是一樣的:這些依賴(lài)項很難啟動(dòng),交互起來(lái)也很慢,這使得測試比平時(shí)更容易失敗。
輸入 DI
為了避免這個(gè)問(wèn)題,您可以創(chuàng )建一個(gè)接口(例如 Vehicle),使 FrogMan 類(lèi)接受 Vehicle 作為一個(gè)構造函數參數,如清單 3 所示:
清單 3. 依賴(lài)接口并注入它們
- public class FrogMan {
- private Vehicle vehicle;
- public FrogMan(Vehicle vehicle) {
- this.vehicle = vehicle;
- }
- // crime fighting logic goes here...
- }
這種用法就是 DI 的本質(zhì) — 使類(lèi)通過(guò)引用接口而不是構建接口(或使用靜態(tài)引用)來(lái)接受它們的依賴(lài)項。清單 4 顯示了 DI 如何使測試變得更簡(jiǎn)單:
清單 4. 測試可以使用 mock 而不是麻煩的依賴(lài)項
- static class MockVehicle implements Vehicle {
- boolean didZoom;
- public String zoom() {
- this.didZoom = true;
- return "Mock Vehicle Zoomed.";
- }
- }
- public void testFrogManFightsCrime() {
- MockVehicle mockVehicle = new MockVehicle();
- FrogMan hero = new FrogMan(mockVehicle);
- hero.fightCrime();
- assertTrue(mockVehicle.didZoom);
- // other assertions
- }
這個(gè)測試使用了一個(gè)手動(dòng)編寫(xiě)的 mock 對象來(lái)替換 FrogMobile。DI 不僅在測試中省去了麻煩的 refinery 啟動(dòng)過(guò)程,而且使測試不用了解 FrogMobile 具體細節。需要的僅是一個(gè) Vehicle 接口。除了使測試變得更簡(jiǎn)單之外,DI 還有助于提高代碼的總體模塊性和可維護性?,F在,如果想將 FrogMobile 切換為 FrogBarge,可以不修改 FrogMan。所有 FrogMan 都依賴(lài)于 Vehicle 接口。
不過(guò)這里有一個(gè)陷阱。如果您是第一次閱讀 DI,可能會(huì )想:“這下好了,現在所有 FrogMan 的調用方 都必須知道 FrogMobile(refinery、refinery 的依賴(lài)項,依此類(lèi)推……)”。但如果是這樣,DI 就永遠不會(huì )這么流行。您可以不增加調用方的負擔,而是編寫(xiě)一些工廠(chǎng) 來(lái)管理對象及其依賴(lài)項的創(chuàng )建。
工廠(chǎng)是存放框架的地方。工廠(chǎng)需要大量冗長(cháng)重復的代碼。工廠(chǎng)往往會(huì )讓程序員(和讀者)很痛苦,他們甚至會(huì )嫌它麻煩而放棄編寫(xiě)。Guice 和其他 DI 框架可作為 “超級工廠(chǎng)”,您可以通過(guò)配置它們來(lái)構建對象。配置 DI 框架比自己編寫(xiě)工廠(chǎng)容易得多。因此,程序員編寫(xiě)的代碼大部分是 DI 樣式的。測試越多代碼就越好,程序員以后也就越省事。
通過(guò) Guice 進(jìn)行基本注入
我希望在我的介紹之后,您會(huì )相信 DI 能為您的設計增加價(jià)值,而且使用框架會(huì )使工作更輕松?,F在讓我們從 @Inject 注釋和模塊開(kāi)始深入討論 Guice。
告訴 Guice 給類(lèi)添加 @Inject
FrogMan 與 Guice 上的 FrogMan 之間的唯一區別是 @Inject。清單 5 顯示了 FrogMan 帶有注釋的構造函數:
清單 5. FrogMan 已經(jīng)加上 @Inject
- @Inject
- public FrogMan(Vehicle vehicle) {
- this.vehicle = vehicle;
- }
一些工程師不喜歡給類(lèi)添加 @Inject。他們更喜歡一個(gè)完全忽略 DI 框架的類(lèi)。這種說(shuō)法有一定道理,但是我不大贊同。依賴(lài)項的注入會(huì )使注釋的作用更加明顯。@Inject 標記只在您要求 Guice 構建類(lèi)時(shí)才有意義。如果不要求 Guice 構建 FrogMan,這個(gè)注釋對代碼行為就沒(méi)有任何影響。這個(gè)注釋恰當地指出了 Guice 將參與構建類(lèi)。但是,使用它需要源代碼級別的訪(fǎng)問(wèn)。如果這個(gè)注釋帶來(lái)不便,或者正在使用 Guice 創(chuàng )建無(wú)法控制其源代碼的對象,那么 Guice 就會(huì )用一個(gè)替代機制。
告訴 Guice 您需要哪個(gè)依賴(lài)項
Guice 知道您的 hero 需要一個(gè) Vehicle 后,它需要知道提供什么 Vehicle。清單 6 包含一個(gè) Module:一個(gè)特殊的類(lèi),用于告訴 Guice 各個(gè)接口對應的實(shí)現。
清單 6. HeroModule 將 Vehicle 綁定到 FrogMobile
- public class HeroModule implements Module {
- public void configure(Binder binder) {
- binder.bind(Vehicle.class).to(FrogMobile.class);
- }
- }
模塊就是一個(gè)具有某種單實(shí)例對象方法的接口。Guice 傳遞給模塊的 Binder 用于告訴 Guice 您想如何構造對象。綁定程序 API 形成一種 區域特定語(yǔ)言。這種小語(yǔ)言允許您編寫(xiě)表達式代碼,比如 bind(X).to(Y).in(Z)。后面將提供更多有關(guān)綁定程序作用的例子。每次調用 bind 都會(huì )創(chuàng )建一個(gè)綁定,Guice 將使用綁定集解析注入請求。
使用 Injector 啟動(dòng)
然后,使用 Injector 類(lèi)啟動(dòng) Guice。通常需要盡早在程序中創(chuàng )建注入器。這樣 Guice 能夠幫助您創(chuàng )建大部分對象。清單 7 包含一個(gè)以 Injector 開(kāi)始的示例 main 程序:
清單 7 使用 Injector 啟動(dòng)應用程序
- public class Adventure {
- public static void main(String[] args){
- Injector injector = Guice.createInjector(new HeroModule());
- FrogMan hero = injector.getInstance(FrogMan.class);
- hero.fightCrime();
- }
- }
為了獲取注入器,需要在 Guice 類(lèi)上調用 createInjector。向 createInjector 傳遞一個(gè)模塊列表,用于配置它本身(本例只有一個(gè),但您可以添加一個(gè)配置 evildoer 的 VillainModule)。擁有注入器后,使用 getInstance 向它請求對象,傳遞您想返回的 .class(細心的讀者會(huì )注意到您不需要告訴 Guice 有關(guān) FrogMan 的信息。如果您請求一個(gè)具體類(lèi),而它有一個(gè) @Inject 構造函數或公共非參數構造函數的話(huà),Guice 就會(huì )創(chuàng )建這個(gè)類(lèi),而無(wú)需調用 bind)。
這是 Guice 構造對象的第一種方式:顯式詢(xún)問(wèn)。但是,您不會(huì )希望在啟動(dòng)例程之外使用這個(gè)操作。更好、更簡(jiǎn)單的方式是讓 Guice 注入依賴(lài)項、依賴(lài)項的依賴(lài)項,依此類(lèi)推(正如諺語(yǔ)所說(shuō):“背起地球的海龜站在另一個(gè)海龜的背上”)。最初看來(lái),這似乎比較麻煩,但您很快就會(huì )習慣這種用法。例如,清單 8 顯示了一個(gè)注入了 FuelSource 的 FrogMobile:
清單 8. FrogMobile 接受一個(gè) FuelSource
- @Inject
- public FrogMobile(FuelSource fuelSource){
- this.fuelSource = fuelSource;
- }
這意味著(zhù),當您檢索 FrogMan 時(shí),Guice 會(huì )構建一個(gè) FuelSource、一個(gè) FrogMobile,最后是一個(gè) FrogMan。即使應用程序與注入器只交互一次,也是如此。
當然,您并不總是有機會(huì )控制應用程序的 main 例程。例如,許多 Web 框架自動(dòng)構建 “操作”、“模板” 或其他一些初始服務(wù)??偸强梢哉业揭粋€(gè)地方插入 Guice,不管是使用該框架的一個(gè)插件,還是使用一些自己手動(dòng)編寫(xiě)的代碼(例如,Guice 項目發(fā)布了一個(gè) Struts 2 插件,它允許 Guice 配置您的 Strut 操作)。
通過(guò) Guice 進(jìn)行依賴(lài)項注入(2)
其他注入形式
到目前為止,我展示了 @Inject 應用于構造函數的用法。當 Guice 找到注釋時(shí),它會(huì )挑選構造函數參數,并試圖為每個(gè)參數找到一個(gè)配置綁定。這稱(chēng)為 構造函數注入。根據 Guice 的最佳實(shí)踐指南,構造函數注入是詢(xún)問(wèn)依賴(lài)項的首選方式。但這不是唯一的方式。清單 9 顯示了配置 FrogMan 類(lèi)的另一種方式:
清單 9. 方法注入
- public class FrogMan{
- private Vehicle vehicle;
- @Inject
- public void setVehicle(Vehicle vehicle) {
- this.vehicle = vehicle;
- }
- //etc. ...
注意,我沒(méi)有使用注入的構造函數,而是改用一個(gè)帶有 @Inject 標記的方法。Guice 會(huì )在構造好 hero 之后立即調用此方法。Spring 框架的忠實(shí)用戶(hù)可以將此方法視為 “setter 注入”。不過(guò),Guice 只關(guān)心 @Inject;您可以任意命名這個(gè)方法,它可以帶有多個(gè)參數。此方法可以是包保護的,也可以是私有方法。
如果您認為 Guice 訪(fǎng)問(wèn)私有方法不是很好,可以參見(jiàn)清單 10,其中 FrogMan 使用了字段注入:
清單 10. 字段注入
- public class FrogMan {
- @Inject private Vehicle vehicle;
- public FrogMan(){}
- //etc. ...
同樣,所有 Guice 都只關(guān)心 @Inject 注釋。字段注入查找注釋的所有字段并試圖注入相應的依賴(lài)項。
哪種方法最好
三個(gè) FrogMan 版本都展示了相同的行為:Guice 在構建時(shí)注入相應的 Vehicle。不過(guò),像 Guice 的作者一樣,我更喜歡構造函數注入。下面簡(jiǎn)單分析這三種方式:
- 構造函數注入 很簡(jiǎn)單。因為 Java 技術(shù)能保證構造函數調用,您不用擔心出現未初始化的對象 — 不管是不是由 Guice 創(chuàng )建的。您還可以將字段標記為 final。
- 字段注入 會(huì )影響可測試性,特別是將字段標記為 private 時(shí)。這破壞了使用 DI 的主要目的。應該盡量少使用字段注入。
- 方法注入 在您不控制類(lèi)的實(shí)例化時(shí)很有用。如果您有一個(gè)需要某些依賴(lài)項的超類(lèi),也可以使用方法注入(構造函數注入會(huì )使這種情況變得很復雜)。
選擇實(shí)現
現在,假設應用程序中有多個(gè) Vehicle。一樣英勇的 Weasel Girl 無(wú)法駕馭 FrogMobile!同時(shí),您不想在 WeaselCopter 上硬編碼依賴(lài)項。清單 11 顯示了 Weasel Girl 請求一種更快的傳輸模式:
清單 11. 使用注釋請求某種特定的實(shí)現
- @Inject
- public WeaselGirl(@Fast Vehicle vehicle) {
- this.vehicle = vehicle;
- }
在清單 12 中,HeroModule 使用綁定函數告訴 Guice WeaselCopter 是 “很快” 的:
清單 12. 告訴 Guice Module 中的相關(guān)注釋
- public class HeroModule implements Module {
- public void configure(Binder binder) {
- binder.bind(Vehicle.class).to(FrogMobile.class);
- binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);
- }
- }
注意,我選擇了一個(gè)注釋?zhuān)枋鑫蚁胍猿橄笮问矫枋龅墓ぞ叻N類(lèi)(@Fast),而不是與實(shí)現太接近的注釋?zhuān)ˊWeaselCopter)。如果您使用的注釋將想要的實(shí)現描述得太精確,就讓讀者覺(jué)得創(chuàng )建一個(gè)隱式依賴(lài)項。如果使用 @WeaselCopter,而且 Weasel Girl 借用了 Wombat Rocket,就會(huì )對程序員閱讀和調試代碼造成混淆。
要創(chuàng )建 @Fast 注釋?zhuān)枰獜椭魄鍐?13 中的模板:
清單 13. 復制粘貼這段代碼以創(chuàng )建一個(gè)綁定注釋
- @Retention(RetentionPolicy.RUNTIME)
- @Target({ElementType.FIELD, ElementType.PARAMETER})
- @BindingAnnotation
- public @interface Fast {}
如果您編寫(xiě)了大量 BindingAnnotations,就會(huì )得到許多這樣的小文件,每個(gè)文件只是注釋名稱(chēng)不同。如果您覺(jué)得這很繁瑣,或者需要執行快速的原型設計,可以考慮 Guice 的內置 @Named 注釋?zhuān)邮芤粋€(gè)字符串屬性。清單 14 展示了這種替代方法:
清單 14. 使用 @Named 代替自定義注釋
- // in WeaselGirl
- @Inject
- public WeaselGirl(@Named("Fast") Vehicle vehicle) {
- //...
- }
- // in HeroModule
- binder.bind(Vehicle.class)
- .annotatedWith(Names.named("Fast")).to(WeaselCopter.class);
這種方法是可行的,但由于名稱(chēng)只在字符串內有效,所以這不能利用編譯時(shí)檢查和自動(dòng)補齊??偟膩?lái)說(shuō),我更愿意自己編寫(xiě)注釋。
如果您根本不想使用注釋?zhuān)趺崔k?即使添加 @Fast 或 @Named("Fast") 都會(huì )使類(lèi)在某種程度上影響配置本身。如果想知道如何解決這個(gè)問(wèn)題,請接著(zhù)閱讀。
provider 方法
如果每次探險都派遣 Frog Man,您可能會(huì )厭煩。您喜歡在每個(gè)場(chǎng)景中出現的 hero 是隨機的。但是,Guice 的默認綁定程序 API 不允許出現 “每次調用時(shí)將 Hero 類(lèi)綁定到一個(gè)不同的實(shí)現” 這樣的調用。不過(guò),您可以 告訴 Guice 使用一種特殊的方法來(lái)創(chuàng )建每個(gè)新的 Hero。清單 15 顯示了將一個(gè)新方法添加到 HeroModule 中,并用特殊的 @Provides 注釋進(jìn)行注釋?zhuān)?/p>
清單 15. 使用 provider 編寫(xiě)自定義創(chuàng )建邏輯
- @Provides
- private Hero provideHero(FrogMan frogMan, WeaselGirl weaselGirl) {
- if (Math.random() > .5) {
- return frogMan;
- }
- return weaselGirl;
- }
Guice 會(huì )自動(dòng)發(fā)現具有 @Provides 注釋的 Module 中的所有方法。根據 Hero 的返回類(lèi)型,在您請求某個(gè) hero 時(shí),Guice 會(huì )進(jìn)行計算,它應該調用 provider 方法來(lái)提供 hero。您可以為 provider 方法添加邏輯以構建對象并在緩存中查詢(xún)它,或者通過(guò)其他方式獲得它。provider 方法是將其他庫集成到 Guice 模塊中的很好方式。它們也是從 Guice 2.0 開(kāi)始提供的新方法(Guice 1.0 中只編寫(xiě)自定義 provider 類(lèi),這比較乏味,而且更加繁瑣。如果您已經(jīng)決定使用 Guice 1.0,用戶(hù)指南中有這種舊方法的文檔,而且在本文隨附的 示例