http://code.google.com/p/google-guice/


用 Guice 寫 Java
Guice 1.0 用戶指南

?

（20070326 王詠剛 譯自：http://docs.google.com/Doc?id=dd2fhx4z_5df5hw8）

Guice (讀作"juice")是超輕量級的，下一代的，為Java 5及后續(xù)版本設(shè)計的依賴注入容器。

簡介

Java企業(yè)應(yīng)用開發(fā)社區(qū)在連接對象方面花了很大功夫。你的Web應(yīng)用如何訪問中間層服務(wù)？你的服務(wù)如何連接到登錄用戶和事務(wù)管理器？關(guān)于這個問題你會發(fā)現(xiàn)很多通用的和特定的解決方案。有一些方案依賴于模式，另一些則使用框架。所有這些方案都會不同程度地引入一些難于測試或者程式化代碼重復(fù)的問題。你馬上就會看到，Guice 在這方面是全世界做得最好的：非常容易進(jìn)行單元測試，最大程度的靈活性和可維護性，以及最少的代碼重復(fù)。

我們使用一個假想的、簡單的例子來展示 Guice 優(yōu)于其他一些你可能已經(jīng)熟悉的經(jīng)典方法的地方。下面的例子過于簡單，盡管它展示了許多顯而易見的優(yōu)點，但其實它還遠(yuǎn)沒有發(fā)揮出 Guice 的全部潛能。我們希望，隨著你的應(yīng)用開發(fā)的深入，Guice 的優(yōu)越性也會更多地展現(xiàn)出來。

在這個例子中，一個客戶對象依賴于一個服務(wù)接口。該服務(wù)接口可以提供任何服務(wù)，我們把它稱為Service。

public interface Service {

? void go();
}

?

對于這個服務(wù)接口，我們有一個缺省的實現(xiàn)，但客戶對象不應(yīng)該直接依賴于這個缺省實現(xiàn)。如果我們將來打算使用一個不同的服務(wù)實現(xiàn)，我們不希望回過頭來修改所有的客戶代碼。

public class ServiceImpl implements Service {

? public void go() {

??? ...

? }

}

我們還有一個可用于單元測試的偽服務(wù)對象。

public class MockService implements Service {

? private boolean gone = false;

? public void go() {
??? gone = true;
? }

? public boolean isGone() {
??? return gone;
? }
}

簡單工廠模式?

在發(fā)現(xiàn)依賴注入之前，最常用的是工廠模式。除了服務(wù)接口之外，你還有一個既可以向客戶提供服務(wù)對象，也可以向測試程序傳遞偽服務(wù)對象的工廠類。在這里我們會將服務(wù)實現(xiàn)為一個單件對象，以便讓示例盡量簡化。

public class ServiceFactory {

? private ServiceFactory() {}
???
? private static Service instance = new ServiceImpl();

? public static Service getInstance() {
??? return instance;
? }
?
? public static void setInstance(Service service) {
??? instance = service;
? }
}

客戶程序每次需要服務(wù)對象時就直接從工廠獲取。

public class Client {

? public void go() {
??? Service service = ServiceFactory.getInstance();
??? service.go();
? }
}

客戶程序足夠簡單。但客戶程序的單元測試代碼必須將一個偽服務(wù)對象傳入工廠，同時要記得在測試后清理。在我們這個簡單的例子里，這不算什么難事兒。但當(dāng)你增加了越來越多的客戶和服務(wù)代碼后，所有這些偽代碼和清理代碼會讓單元測試的開發(fā)一團糟。此外，如果你忘記在測試后清理，其他測試可能會得到與預(yù)期不符的結(jié)果。更糟的是，測試的成功與失敗可能取決于他們被執(zhí)行的順序。

public void testClient() {
? Service previous = ServiceFactory.getInstance();
? try {
??? final MockService mock = new MockService();
??? ServiceFactory.setInstance(mock);
??? Client client = new Client();
??? client.go();
??? assertTrue(mock.isGone());
? }
? finally {
??? ServiceFactory.setInstance(previous);
? }
}

最后，注意服務(wù)工廠的API把我們限制在了單件這一種應(yīng)用模式上。即便 getInstance() 可以返回多個實例， setInstance() 也會束縛我們的手腳。轉(zhuǎn)換到非單件模式也意味著轉(zhuǎn)換到了一套更復(fù)雜的API。

手工依賴注入

依賴注入模式的目標(biāo)之一是使單元測試更簡單。我們不需要特殊的框架就可以實踐依賴注入模式。依靠手工編寫代碼，你可以得到該模式大約80%的好處。

當(dāng)上例中的客戶代碼向工廠對象請求一個服務(wù)時，根據(jù)依賴注入模式，客戶代碼希望它所依賴的對象實例可以被傳入自己。也就是說：不要調(diào)用我，我會調(diào)用你。

public class Client {
???
? private final Service service;

? public Client(Service service) {
??? this.service = service;
? }

? public void go() {
??? service.go();
? }
}

這讓我們的單元測試簡化了不少。我們可以只傳入一個偽服務(wù)對象，在結(jié)束后也不需要多做什么。

public void testClient() {
? MockService mock = new MockService();
? Client client = new Client(mock);
? client.go();
? assertTrue(mock.isGone());
}

我們也可以精確地區(qū)分出客戶代碼依賴的API。

現(xiàn)在，我們?nèi)绾芜B接客戶和服務(wù)對象呢？手工實現(xiàn)依賴注入的時候，我們可以將所有依賴邏輯都移動到工廠類中。也就是說，我們還需要有一個工廠類來創(chuàng)建客戶對象。

public static class ClientFactory {

? private ClientFactory() {}

? public static Client getInstance() {
??? Service service = ServiceFactory.getInstance();
??? return new Client(service);
? }
}

手工實現(xiàn)依賴注入需要的代碼行數(shù)和簡單工廠模式差不多。

用 Guice 實現(xiàn)依賴注入

手工為每一個服務(wù)與客戶實現(xiàn)工廠類和依賴注入邏輯是一件很麻煩的事情。其他一些依賴注入框架甚至需要你顯式將服務(wù)映射到每一個需要注入的地方。

Guice 希望在不犧牲可維護性的情況下去除所有這些程式化的代碼。

使用 Guice，你只需要實現(xiàn)模塊類。Guice 將一個綁定器傳入你的模塊，你的模塊使用綁定器來連接接口和實現(xiàn)。以下模塊代碼告訴 Guice 將 Service?映射到單件模式的 ServiceImpl：

public class MyModule implements Module {
? public void configure(Binder binder) {
??? binder.bind(Service.class)
????? .to(ServiceImpl.class)
????? .in(Scopes.SINGLETON);
? }
}

模塊類告訴 Guice 我們想注入什么東西。那么，我們該如何告訴 Guice 我們想把它注入到哪里呢？使用 Guice，你可以使用 @Inject 標(biāo)注你的構(gòu)造器，方法或字段：

public class Client {

? private final Service service;

? @Inject
? public Client(Service service) {
??? this.service = service;
? }

? public void go() {
??? service.go();
? }
}

@Inject 標(biāo)注可以清楚地告訴其他程序員你的類中哪些成員是被注入的。

為了讓 Guice?向 Client 中注入，我們必須直接讓 Guice 幫我們創(chuàng)建?Client 的實例，或者，其他類必須包含被注入的?Client 實例。

Guice vs. 手工依賴注入

如你所見，Guice 省去了寫工廠類的麻煩。你不需要編寫代碼將客戶連接到它們所依賴的對象。如果你忘了提供一個依賴關(guān)系，Guice 在啟動時就會失敗。Guice 也會自動處理循環(huán)依賴關(guān)系。

Guice 允許你通過聲明指定對象的作用域。例如，你需要編寫相同的代碼將對象反復(fù)存入 HttpSession。

實際情況通常是，只有到了運行時，你才能知道具體要使用哪一個實現(xiàn)類。因此你需要元工廠類或服務(wù)定位器來增強你的工廠模式。Guice 用最少的代價解決了這些問題。

手工實現(xiàn)依賴注入時，你很容易退回到使用直接依賴的舊習(xí)慣，特別是當(dāng)你對依賴注入的概念還不那么熟悉的時候。使用 Guice 可以避免這種問題，可以讓你更容易地把事情做對。Guice 使你保持正確的方向。

更多的標(biāo)注

只要有可能，Guice 就允許你使用標(biāo)注來替代顯式地綁定對象，以減少更多的程式化代碼。回到我們的例子，如果你需要一個接口來簡化單元測試，而你又不介意編譯時的依賴，你可以直接從你的接口指向一個缺省的實現(xiàn)。

@ImplementedBy(ServiceImpl.class)
public interface Service {
? void go();
}

這時，如果客戶需要一個 Service 對象，且 Guice 無法找到顯式綁定，Guice 就會注入一個 ServiceImpl 的實例。

缺省情況下，Guice 每次都注入一個新的實例。如果你想指定不同的作用域規(guī)則，你也可以對實現(xiàn)類進(jìn)行標(biāo)注。

@Singleton
public class ServiceImpl implements Service {
? public void go() {
??? ...
? }
}

架構(gòu)概覽

我們可以將 Guice 的架構(gòu)分成兩個不同的階段：啟動和運行。你在啟動時創(chuàng)建一個注入器 Injector，在運行時用它來注入對象。

啟動

你通過實現(xiàn) Module 來配置 Guice。你傳給 Guice 一個模塊對象，Guice 則將一個綁定器 Binder 對象傳入你的模塊，然后，你的模塊使用綁定器來配置綁定。一個綁定通常包含一個從接口到具體實現(xiàn)的映射。例如：

public class MyModule implements Module {
? public void configure(Binder binder) {
??? // Bind Foo to FooImpl. Guice will create a new
??? // instance of FooImpl for every injection.
??? binder.bind(Foo.class).to(FooImpl.class);

??? // Bind Bar to an instance of Bar.
??? Bar bar = new Bar();
??? binder.bind(Bar.class).toInstance(bar);
? }
}

在這個階段，Guice 會察看你告訴它的所有類，以及任何與這些類有關(guān)系的類，然后通知你是否有依賴關(guān)系的缺失。例如，在一個?Struts 2 應(yīng)用中，Guice 知道你所有的動作類。Guice 會檢查你的動作類以及它們依賴的所有類，如果有問題會及早報錯。

創(chuàng)建一個 Injector 涉及以下步驟：

首先創(chuàng)建你的模塊類實例，并將其傳入 Guice.createInjector().

Guice 創(chuàng)建一個綁定器 Binder 并將其傳入你的模塊。

你的模塊使用綁定器來定義綁定。

基于你所定義的綁定，Guice 創(chuàng)建一個注入器 Injector 并將其返回給你。

你使用注入器來注入對象。

運行

現(xiàn)在你可以使用第一階段創(chuàng)建的注入器來注入對象并內(nèi)省（introspect）我們的綁定了。Guice 的運行時模型由一個可管理一定數(shù)量綁定的注入器組成。



鍵 Key 唯一地確定每一個綁定。?Key 包含了客戶代碼所依賴的類型以及一個可選的標(biāo)注。你可以使用標(biāo)注來區(qū)分指向同一類型的多個綁定。?Key 的類型和標(biāo)注對應(yīng)于注入時的類型和標(biāo)注。

每個綁定有一個提供者 provider，它提供所需類型的實例。你可以提供一個類，Guice 會幫你創(chuàng)建它的實例。你也可以給 Guice 一個你要綁定的類的實例。你還可以實現(xiàn)你自己的 provider，Guice 可以向其中注入依賴關(guān)系。

每個綁定還有一個可選的作用域。缺省情況下綁定沒有作用域，Guice 為每一次注入創(chuàng)建一個新的對象。一個定制的作用域可以使你控制 Guice 是否創(chuàng)建新對象。例如，你可以為每一個? HttpSession 創(chuàng)建一個實例。

自舉（Bootstrapping）你的應(yīng)用

自舉（bootstrapping）對于依賴注入非常重要。總是顯式地向 Injector 索要依賴，這就將 Guice 用作了服務(wù)定位器，而不是一個依賴注入框架。

你的代碼應(yīng)該盡量少地和 Injector 直接打交道。相反，你應(yīng)該通過注入一個根對象來自舉你的應(yīng)用。容器可以更進(jìn)一步地將依賴注入根對象所依賴的對象，并如此迭代下去。最終，在理想情況下，你的應(yīng)用中應(yīng)該只有一個類知道?Injector，每個其他類都應(yīng)該使用注入的依賴關(guān)系。

例如，一個諸如 Struts 2 的?Web 應(yīng)用框架通過注入你的所有動作類來自舉你的應(yīng)用。你可以通過注入你的服務(wù)實現(xiàn)類來自舉一個 Web 服務(wù)框架。

依賴注入是傳染性的。如果你重構(gòu)一個有大量靜態(tài)方法的已有代碼，你可能會覺得你正在試圖拉扯一根沒有盡頭的線。這是好事情。它表明依賴注入正在幫助你改進(jìn)代碼的靈活性和可測試性。

如果重構(gòu)工作太復(fù)雜，你不想一次性地整理完所有代碼，你可以暫時將一個 Injector 的引用存入某個類的一個靜態(tài)的字段，或是使用靜態(tài)注入。這時，請清楚地命名包含該字段的類：比如 InjectorHack?和 GodKillsAKittenEveryTimeYouUseMe。記住你將來可能不得不為這些類提供偽測試類，你的單元測試則不得不手工安裝一個注入器。記住，你將來需要清理這些代碼。

綁定依賴關(guān)系

Guice 是如何知道要注入什么東西的呢？對啟動器來說，一個包含了類型和可選的標(biāo)注的 Key 唯一地指明了一個依賴關(guān)系。Guice 將 key?和實現(xiàn)之間的映射標(biāo)記為一個 Binding。一個實現(xiàn)可以包含一個單獨的對象，一個需要由 Guice 注入的類，或一個定制的 provider。

當(dāng)注入依賴關(guān)系時，Guice 首先尋找顯式綁定，即你通過綁定器 Binder?指明的綁定。Binder API 使用生成器（Builder）模式來創(chuàng)建一種領(lǐng)域相關(guān)的描述語言。根據(jù)約束適用方法的上下文的不同，不同方法返回不同的對象。

例如，為了將接口 Service 綁定到一個具體的實現(xiàn) ServiceImpl，調(diào)用：

binder.bind(Service.class).to(ServiceImpl.class);

該綁定與下面的方法匹配：

@Inject
void injectService(Service service) {
? ...
}
注: 與某些其他的框架相反，Guice 并沒有給 "setter" 方法任何特殊待遇。不管方法有幾個參數(shù)，只要該方法含有 @Inject?標(biāo)注，Guice?就會實施注入，甚至對基類中實現(xiàn)的方法也不例外。

不要重復(fù)自己

對每個綁定不斷地重復(fù)調(diào)用?"binder" 似乎有些乏味。Guice 提供了一個支持 Module 的類，名為 AbstractModule，它隱含地賦予你訪問 Binder 的方法的權(quán)力。例如，我們可以用擴展 AbstractModule 類的方式改寫上述綁定：

bind(Service.class).to(ServiceImpl.class);

在本手冊的余下部分中我們會一直使用這樣的語法。

標(biāo)注綁定

? 如果你需要指向同一類型的多個綁定，你可以用標(biāo)注來區(qū)分這些綁定。例如，將接口 Service 和標(biāo)注 @Blue 綁定到具體的實現(xiàn)類 BlueService 的代碼如下：

bind(Service.class)
? .annotatedWith(Blue.class)
? .to(BlueService.class);

這個綁定會匹配以下方法：

@Inject
void injectService(@Blue Service service) {
? ...
}

注意，標(biāo)注 @Inject 出現(xiàn)在方法前，而綁定標(biāo)注（如 @Blue）則出現(xiàn)在參數(shù)前。對構(gòu)造函數(shù)也是如此。使用字段注入時，兩種標(biāo)注都直接應(yīng)用于字段，如以下代碼：

@Inject @Blue Service service;

創(chuàng)建綁定標(biāo)注

剛才提到的標(biāo)注 @Blue 是從哪里來的？你可以很容易地創(chuàng)建這種標(biāo)注，但不幸的是，你必須使用略顯復(fù)雜的標(biāo)準(zhǔn)語法：

/**
?* Indicates we want the blue version of a binding.
?*/
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.FIELD, ElementType.PARAMETER})
@BindingAnnotation
public @interface Blue {}

幸運的是，我們不需要理解這些代碼，只要會用就可以了。對于好奇心強的朋友，下面是這些程式化代碼的含義：

• @Retention(RUNTIME) 使得你的標(biāo)注在運行時可見。
• @Target({FIELD, PARAMETER}) 是對用戶使用的說明；它不允許 @Blue 被用于方法、類型、局部變量和其他標(biāo)注。
• @BindingAnnotation 是 Guice 特定的信號，表示你希望該標(biāo)注被用于綁定標(biāo)注。當(dāng)用戶將多于一個的綁定標(biāo)注應(yīng)用于同一個可注入元素時，Guice 會報錯。

有屬性的標(biāo)注

如果你已經(jīng)會寫有屬性的標(biāo)注了，請?zhí)较乱还?jié)。

你也可以綁定到標(biāo)注實例，即，你可以有多個綁定指向同樣的類型和標(biāo)注類型，但每個綁定擁有不同的標(biāo)注屬性值。如果 Guice 找不到擁有特定屬性值的標(biāo)注實例，它會去找一個綁定到該標(biāo)注類型的綁定。

例如，我們有一個綁定標(biāo)注 @Named，它有一個字符串屬性值。 @Retention(RUNTIME)
@Target({ FIELD, PARAMETER })
@BindingAnnotation
public @interface Named {
String value();
}
如果我們希望綁定到 @Named("Bob")，我們首先需要一個 Named 的實現(xiàn)。我們的實現(xiàn)必須遵守關(guān)于 Annotation 的約定，特別是 hashCode()?和 equals() 的實現(xiàn)。
class NamedAnnotation implements Named {

final String value;

public NamedAnnotation(String value) {
this.value = value;
}

public String value() {
return this.value;
}

public int hashCode() {
// This is specified in java.lang.Annotation.
return 127 * "value".hashCode() ^ value.hashCode();
}

public boolean equals(Object o) {
if (!(o instanceof Named))
return false;
Named other = (Named) o;
return value.equals(other.value());
}

public String toString() {
return "@" + Named.class.getName() + "(value=" + value + ")";
}

public Class<? extends Annotation> annotationType() {
return Named.class;
}
} 現(xiàn)在我們可以使用這個標(biāo)注實現(xiàn)來創(chuàng)建一個指向 @Named 的綁定。

bind(Person.class)
? .annotatedWith(new NamedAnnotation("Bob"))
? .to(Bob.class);

與其它框架使用基于字符串的標(biāo)識符相比，這顯得有些繁瑣，但記住，使用基于字符串的標(biāo)識符，你根本無法這樣做。而且，你會發(fā)現(xiàn)你可以大量復(fù)用已有的綁定標(biāo)注。

因為通過名字標(biāo)記一個綁定非常普遍，以至于 Guice 在?com.google.inject.name 中提供了一個十分有用的 @Named 的實現(xiàn)。

隱式綁定

正如我們在簡介中看到的那樣，你并不總是需要顯式地聲明綁定。如果缺少顯式綁定，Guice 會試圖注入并創(chuàng)建一個你所依賴的類的新實例。如果你依賴于一個接口，Guice 會尋找一個指向具體實現(xiàn)的?@ImplementedBy 標(biāo)注。例如，下例中的代碼顯式綁定到一個具體的、可注入的名為 Concrete 的類。它的含義是，將 Concrete?綁定到 Concrete。這是顯式的聲明方式，但也有些冗余。

bind(Concrete.class);

刪除上述綁定語句不會影響下面這個類的行為：

class Mixer {

? @Inject
? Mixer(Concrete concrete) {
??? ...
? }
}

好吧，你自己來選擇：顯式的或簡略的。無論何種方式，Guice 在遇到錯誤時都會生成有用的信息。

注入提供者

有時對于每次注入，客戶代碼需要某個依賴的多個實例。其它時候，客戶可能不想在一開始就真地獲取對象，而是等到注入后的某個時候再獲取。對于任意綁定類型 T，你可以不直接注入 T 的實例，而是注入一個 Provider<T>，然后在需要的時候調(diào)用 Provider<T>.get()，例如：

@Inject
void injectAtm(Provider<Money> atm) {
? Money one = atm.get();
? Money two = atm.get();
? ...
}

正如你所看到的那樣， Provider 接口簡單得不能再簡單了，它不會為簡單的單元測試添加任何麻煩。

注入常數(shù)值

對于常數(shù)值，Guice 對以下幾種類型做了特殊處理：

• 基本類型(int, char, ...)
• 基本封裝類型(Integer, Character, ...)
• Strings
• Enums
• Classes

首先，當(dāng)綁定到這些類型的常數(shù)值的時候，你不需要指定你要綁定到的類型。Guice 可以根據(jù)值判斷類型。例如，一個綁定標(biāo)注名為 TheAnswer：

bindConstant().annotatedWith(TheAnswer.class).to(42);

它的效果等價于：

bind(int.class).annotatedWith(TheAnswer.class).toInstance(42);

當(dāng)需要注入這些類型的數(shù)值時，如果 Guice 找不到指向基本數(shù)據(jù)類型的顯式綁定，它會找一個指向相應(yīng)的封裝類型的綁定，反之亦然。

轉(zhuǎn)換字符串

如果 Guice 仍然無法找到一個上述類型的顯式綁定，它會去找一個擁有相同綁定標(biāo)注的常量 String 綁定，并試圖將字符串轉(zhuǎn)換到相應(yīng)的值。例如：

bindConstant().annotatedWith(TheAnswer.class).to("42"); // String!

會匹配：

@Inject @TheAnswer int answer;

轉(zhuǎn)換時，Guice 會用名字去查找枚舉和類。Guice 在啟動時轉(zhuǎn)換一次，這意味著它提前做了類型檢查。這個特性特別有用，例如，當(dāng)綁定值來自一個屬性文件的時候。

定制的提供者

有時你需要手工創(chuàng)建你自己的對象，而不是讓 Guice 創(chuàng)建它們。例如，你可能不能為來自第三方的實現(xiàn)類添加 @Inject 標(biāo)注。在這種情況下，你可以實現(xiàn)一個定制的 Provider。Guice 甚至可以注入你的提供者類。例如：

class WidgetProvider implements Provider<Widget> {

? final Service service;

? @Inject
? WidgetProvider(Service service) {
??? this.service = service;
? }

? public Widget get() {
??? return new Widget(service);
? }
}

你可以像這樣把 Widget 綁定到 WidgetProvider：

bind(Widget.class).toProvider(WidgetProvider.class);

注入定制的提供者可以使 Guice 提前檢查類型和依賴關(guān)系。定制的提供者可以在任意作用域中使用，而不依賴于他們所創(chuàng)建的類的作用域。缺省情況下，Guice 為每一次注入創(chuàng)建一個新的提供者實例。在上例中，如果每個 Widget 需要它自己的 Service 實例，我們的代碼也沒有問題。通過在工廠類上使用作用域標(biāo)注，或為工廠類創(chuàng)建單獨的綁定，你可以為定制的工廠指定不同的作用域。

示例：與 JNDI 集成

例如我們需要綁定從 JNDI 得到的對象。我們可以仿照下面的代碼實現(xiàn)一個可復(fù)用的定制的提供者。注意我們注入了 JNDI Context：

package mypackage;

import com.google.inject.*;
import javax.naming.*;

class JndiProvider<T> implements Provider<T> {

? @Inject Context context;
? final String name;
? final Class<T> type;

? JndiProvider(Class<T> type, String name) {
??? this.name = name;
??? this.type = type;
? }

? public T get() {
??? try {
????? return type.cast(context.lookup(name));
??? }
??? catch (NamingException e) {
????? throw new RuntimeException(e);
??? }
? }

? /**
?? * Creates a JNDI provider for the given
?? * type and name.
?? */
? static <T> Provider<T> fromJndi(
????? Class<T> type, String name) {
??? return new JndiProvider<T>(type, name);
? }
}

感謝泛型擦除（generic type erasure）技術(shù)。我們必須在運行時將依賴傳入類中。你可以省略這一步，但在今后跟蹤類型轉(zhuǎn)換錯誤會比較棘手（當(dāng) JNDI 返回錯誤類型的對象的時候）。

我們可以使用定制的 JndiProvider 來將 DataSource 綁定到來自 JNDI 的一個對象：

import com.google.inject.*;
import static mypackage.JndiProvider.fromJndi;
import javax.naming.*;
import javax.sql.DataSource;

...

// Bind Context to the default InitialContext.
bind(Context.class).to(InitialContext.class);

// Bind to DataSource from JNDI.
bind(DataSource.class)
??? .toProvider(fromJndi(DataSource.class, "..."));

限制綁定的作用域

缺省情況下，Guice 為每次注入創(chuàng)建一個新的對象。我們把它稱為“無作用域”。你可以在配制綁定時指明作用域。例如，每次注入相同的實例：

bind(MySingleton.class).in(Scopes.SINGLETON);

另一種做法是，你可以在實現(xiàn)類中使用標(biāo)注來指明作用域。Guice 缺省支持 @Singleton：
@Singleton
class MySingleton {
? ...
}

使用標(biāo)注的方法對于隱式綁定也同樣有效，但需要 Guice 來創(chuàng)建你的對象。另一方面，調(diào)用 in() 適用于幾乎所有綁定類型（顯然，綁定到一個單獨的實例是個例外）并且會忽略已有的作用域標(biāo)注。如果你不希望引入對于作用域?qū)崿F(xiàn)的編譯時依賴，in() 還可以接受標(biāo)注。

可以使用 Binder.bindScope() 為定制的作用域指定標(biāo)注。例如，對于標(biāo)注 @SessionScoped 和一個 Scope 的實現(xiàn) ServletScopes.SESSION：

binder.bindScope(SessionScoped.class, ServletScopes.SESSION);

創(chuàng)建作用域標(biāo)注

用于指定作用域的標(biāo)注必須：

• 有一個 @Retention(RUNTIME) 標(biāo)注，從而使我們可以在運行時看到該標(biāo)注。
• 有一個 @Target({TYPE}) 標(biāo)注。作用域標(biāo)注只用于實現(xiàn)類。
• 有一個 @ScopeAnnotation 元標(biāo)注。一個類只能使用一個此類標(biāo)注。

例如：

/**
?* Scopes bindings to the current transaction.
?*/
@Retention(RUNTIME)
@Target({TYPE})
@ScopeAnnotation
public @interface TransactionScoped {}

盡早加載綁定

Guice 可以等到你實際使用對象時再加載單件對象。這有助于開發(fā)，因為你的應(yīng)用程序可以快速啟動，只初始化你需要的對象。但是，有時你總是希望在啟動時加載一個對象。你可以告訴 Guice，讓它總是盡早加載一個單件對象，例如：

bind(StartupTask.class).asEagerSingleton();
我們經(jīng)常在我們的應(yīng)用程序中使用這個方法實現(xiàn)初始化邏輯。你可以通過在 Guice 必須首先初始化的單件對象上創(chuàng)建依賴關(guān)系來控制初始化順序。

在不同作用域間注入

你可以安全地將來自大作用域的對象注入到來自小作用域或相同作用域的對象中。例如，你可以將一個作用域為 HTTP 會話的對象注入到作用域為 HTTP 請求的對象中。但是，向較大作用域的對象中注入就是另一件事了。例如，如果你把一個作用域為 HTTP 請求的對象注入到一個單件對象中，最好情況下，你會得到無法在 HTTP 請求中運行的錯誤信息，最壞情況下，你的單件對象會總是引用來自第一個 HTTP 請求的對象。在這些時候，你應(yīng)該注入一個 Provider<T>，然后在需要的時候使用它從較小的作用域中獲取對象。這時，你必須確保，在 T 的作用域之外，永遠(yuǎn)不要調(diào)用這個提供者（例如，當(dāng)目前沒有 HTTP 請求且 T 的作用域為 HTTP 請求的時候）。

開發(fā)階段

Guice 明白你的應(yīng)用開發(fā)需要經(jīng)歷不同的階段。你可以在創(chuàng)建容器時告訴它應(yīng)用程序運行在哪一個階段。Guice 目前支持“開發(fā)”和“產(chǎn)品”兩個階段。我們發(fā)現(xiàn)測試通常屬于其中某一個階段。

在開發(fā)階段，Guice 會根據(jù)需要加載單件對象。這樣，你的應(yīng)用程序可以快速啟動，只加載你正在測試的部分。

在產(chǎn)品階段，Guice 會在啟動時加載全部單件對象。這幫助你盡早捕獲錯誤，提前優(yōu)化性能。

你的模塊也可以使用方法攔截和其他基于當(dāng)前階段的綁定。例如，一個攔截器可能會在開發(fā)階段檢查你是否在作用域之外使用對象。

攔截方法

Guice 使用 AOP Alliance API?支持簡單的方法攔截。你可以在模塊中使用 Binder 綁定攔截器。例如，對標(biāo)注有 @Transactional 的方法應(yīng)用事務(wù)攔截器：

import static com.google.inject.matcher.Matchers.*;

...

binder.bindInterceptor(
? any(),????????????????????????????? // Match classes.
? annotatedWith(Transactional.class), // Match methods.
? new TransactionInterceptor()??????? // The interceptor.
);

盡量讓匹配代碼多做些過濾工作，而不是在攔截器中過濾。因為匹配代碼只在啟動時運行一次。

靜態(tài)注入

靜態(tài)字段和方法會增加測試和復(fù)用的難度，但有的時候你唯一的選擇就是保留一個 Injector 的靜態(tài)引用。 ? 在這些情況下，Guice 支持注入可訪問性較少的靜態(tài)方法。例如，HTTP 會話對象經(jīng)常需要被串行化，以支持復(fù)制機制。但是，如果你的會話對象依賴于一個作用域為容器生命周期的對象，該怎么辦呢？我們可以保留一個該對象的臨時引用，但在反串行化的時候，我們該如何再次找到該對象呢？
我們發(fā)現(xiàn)更實用的解決方案是使用靜態(tài)注入：
@SessionScoped
class User {

? @Inject
? static AuthorizationService authorizationService;
? ...
}

Guice 從不自動實施靜態(tài)注入。你必須使用 Binder 顯式請求 Injector 在啟動后注入你的靜態(tài)成員：
binder.requestStaticInjection(User.class);

靜態(tài)注入是一個很難避免的禍害，它會使測試難度加大。如果有辦法避開它，你多半會很高興的。

可選注入

有時你的代碼應(yīng)該在無論綁定是否存在的時候都能工作。在這些情況下，你可以使用 @Inject(optional=true)，Guice 會在有綁定可用時，用一個綁定實現(xiàn)覆蓋你的缺省實現(xiàn)。例如：

@Inject(optional=true) Formatter formatter = new DefaultFormatter();
如果誰為 Formatter 創(chuàng)建了一個綁定，Guice 會基于該綁定注入實例。否則，如果 Formatter 不能被注入(參見隱式綁定)，Guice 會忽略可選成員。

可選注入只能應(yīng)用于字段和方法，而不能用于構(gòu)造函數(shù)。對于方法，如果一個參數(shù)的綁定找不到，Guice 就不會注入該方法，即便其他參數(shù)的綁定是可用的。

綁定到字符串

只要有可能，我們就盡量避免使用字符串，因為它們?nèi)菀?span style="font-size:10pt;font-family:'宋體';">被錯誤拼寫，對工具不友好，等等。但使用字符串而不是創(chuàng)建定制的標(biāo)注對于“快而臟”的代碼來說仍是有用的。在這些情況下，Guice 提供了@Named?和 Names。例如，一個到字符串名字的綁定：

import static com.google.inject.name.Names.*;

...

bind(named("bob")).to(10);

會匹配下面的注入點：
@Inject @Named("bob") int score;

Struts 2支持

要在 Struts 2.0.6 或更高版本中安裝 Guice Struts 2?插件，只要將 guice-struts2-plugin-1.0.jar 包含在你的 Web 應(yīng)用的?classpath 中，并在 struts.xml 文件中選擇 Guice 作為你的 ObjectFactory 實現(xiàn)即可：

<constant name="struts.objectFactory" value="guice" />
Guice 會注入所有你的 Struts 2 對象，包括動作和攔截器。你甚至可以設(shè)置動作類的作用域。你也可以在你的 struts.xml 文件中指定 Guice 的?Module：
<constant name="guice.module" value="mypackage.MyModule"/>

如果你的所有綁定都是隱式的，你就根本不用定義模塊了。

一個計數(shù)器的例子

例如，我們試圖統(tǒng)計一個會話中的請求數(shù)目。定義一個在會話中存活的 Counter 對象：

@SessionScoped
public class Counter {

? int count = 0;

? /** Increments the count and returns the new value. */
? public synchronized int increment() {
??? return count++;
? }
}

接下來，我們可以將我們的計數(shù)器注入到動作中：
public class Count {

? final Counter counter;

? @Inject
? public Count(Counter counter) {
??? this.counter = counter;
? }

? public String execute() {
??? return SUCCESS;
? }

? public int getCount() {
??? return counter.increment();
? }
}

然后在 struts.xml 文件中為動作類創(chuàng)建映射：
<action name="Count"
??? class="mypackage.Count">
? <result>/WEB-INF/Counter.jsp</result>
</action>?????

以及一個用于顯示結(jié)果的 JSP 頁面：
<%@ taglib prefix="s" uri="/struts-tags" %>

<html>??
? <body>
??? <h1>Counter Example</h1>
??? <h3><b>Hits in this session:</b>
????? <s:property value="count"/></h3>
? </body>
</html>

我們實際上把這個例子做得比需求更復(fù)雜，以便展示更多的概念。在現(xiàn)實中，我們不需要使用單獨的 Counter?對象，只要把 @SessionScoped 直接應(yīng)用于我們的動作類即可。

JMX 集成

參見?com.google.inject.tools.jmx.

附錄：注入器如何解決注入請求

注入器解決注入請求的過程依賴于已有的綁定和相關(guān)類型中的標(biāo)注。這里是關(guān)于如何解決注入請求的一個概要描述：

觀察被注入元素的 Java 類型和可選的“綁定標(biāo)注”。如果類型是 com.google.inject.Provider<T>，就使用類型 T 解決注入請求。對于（類型，標(biāo)注）對，尋找一個綁定。如果找不到，則跳到步驟4。

沿著綁定鏈檢查。如果該綁定連接到另一個綁定，則沿著這條邊繼續(xù)檢查，直到到達(dá)一個沒有連接到任何后續(xù)綁定的綁定為止。現(xiàn)在我們就為該注入請求找到了最明確的顯式綁定。

如果綁定指明一個實例或一個 Provider 實例，所有事情都做完了；使用這個實例來滿足請求即可。

此時，如果注入請求使用了標(biāo)注類型或值，我們就報告錯誤。

否則，檢查綁定的 Java 類型；如果找到了 @ImplementedBy 標(biāo)注，就實例化該類型。 如果找到了 @ProvidedBy 標(biāo)注，就實例化提供者類并用它來獲取想要的對象。否則試圖實例化類型本身。

?

?

轉(zhuǎn)載于:https://www.cnblogs.com/xiaomaohai/archive/2007/03/27/6157180.html

總結(jié)

以上是生活随笔為你收集整理的Guice 1.0 用户指南的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。