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