开发技术 / Technology
    您的当前位置:网站首页 > 行业洞察 > 开发技术

    Google Guice使用入门

    日期:2015年1月29日  作者:zhjw  来源:互联网    点击:941

    下载Google Guice之后,有以下几个文件:

    Java代码
    1. aopalliance.jar   
    2. guice-1.0.jar   
    3. guice-servlet-1.0.jar   
    4. guice-spring-1.0.jar   
    5. guice-struts2-plugin-1.0.jar  

    本例只使用到guice-1.0.jar文件,将其加入到class path中。

    下面简单地介绍范例:

    范例1:使用com.google.inject.Module接口实现类
     

     

    文件名
    说明
    HelloGuice.java
    业务逻辑接口定义文件
    HelloGuiceImpl.java
    业务逻辑接口实现文件
    HelloGuiceModule.java
    该文件必须实现com.google.inject.Module接口
    TestGuice.java
    测试文件

     

    HelloGuice.java

    Java代码
    1. package cn.jcourse.guice;   
    2.   
    3. /**  
    4.  * HelloGuice接口,用于表达问候  
    5.  */  
    6. public interface HelloGuice {   
    7.     public void sayHello();   
    8. }   

    上面接口中,我们定义了一个方法,sayHello,用于向用户问候。这里我只是做演示用,在实际的业务中,业务逻辑很可能不是这么简单。

    HelloGuiceImpl.java
     

    Java代码
    1. package cn.jcourse.guice.impl;   
    2.   
    3. import cn.jcourse.guice.HelloGuice;   
    4.   
    5. /**    
    6.  * HellGuice实现类  
    7.  */  
    8. public class HelloGuiceImpl implements HelloGuice {   
    9.   
    10.     /* (non-Javadoc)  
    11.      * @see cn.jcourse.guice.HelloGuice#sayHello()  
    12.      */  
    13.     public void sayHello() {   
    14.         System.out.println("Hello Guice!");   
    15.     }   
    16. }  

    该类是HelloGuice接口的实现类,这里我们仅仅是向控制台输出了一个Hello Guice!字符串。

    HelloGuiceModule.java
     

    Java代码
    1. package cn.jcourse.guice;   
    2.   
    3. import cn.jcourse.guice.impl.HelloGuiceImpl;   
    4.   
    5. import com.google.inject.Binder;   
    6. import com.google.inject.Module;   
    7. /**   
    8.  * HelloGuice模块  
    9.  */  
    10. public class HelloGuiceModule implements Module {   
    11.   
    12.     /*  
    13.      * (non-Javadoc)  
    14.      *   
    15.      * @see com.google.inject.Module#configure(com.google.inject.Binder)  
    16.      */  
    17.     public void configure(Binder binder) {   
    18.         binder.bind(HelloGuice.class).to(HelloGuiceImpl.class);   
    19.     }   
    20. }  

    上面的代码用于告知Guice将接口和实现类绑定。

    TestGuice.java
     

    Java代码
    1. package cn.jcourse.guice.test;   
    2.   
    3. import cn.jcourse.guice.HelloGuice;   
    4. import cn.jcourse.guice.HelloGuiceModule;   
    5.   
    6. import com.google.inject.Guice;   
    7. import com.google.inject.Injector;   
    8.   
    9. import junit.framework.TestCase;   
    10.   
    11. /**   
    12.  * 测试Guice  
    13.  */  
    14. public class TestGuice extends TestCase {   
    15.     public void testHelloGuice() {   
    16.         Injector injector = Guice.createInjector(new HelloGuiceModule());   
    17.         HelloGuice helloGuice = injector.getInstance(HelloGuice.class);   
    18.         helloGuice.sayHello();   
    19.     }   
    20. }  

    上面的代码我们使用JUnit来进行单元测试,这里的代码也相对比较简单。

    在编写完上述代码后,我们运行TestGuice类,将会发现它向控制台输出了Hello Guice!。

    范例2:使用Java Annotation

    范例1中,我们自己手工的去配置了绑定关系,当然我们也可以不用那么做。我们可以直接为HelloGuice加上@ImplementedBy注释,而省略掉对com.google.inject.Module的实现。

    HelloGuice.java
     

    Java代码
    1. package cn.jcourse.guice;   
    2.   
    3. import cn.jcourse.guice.impl.HelloGuiceImpl;   
    4.   
    5. import com.google.inject.ImplementedBy;   
    6.   
    7. /**    
    8.  * HelloGuice接口,用于表达问候  
    9.  */  
    10. @ImplementedBy(HelloGuiceImpl.class)   
    11. public interface HelloGuice {   
    12.     public void sayHello();   
    13. }   

    这里我们使用了Guice提供的注解,ImplementedBy,表示该接口由HelloGuiceImpl类实现。这样我们就可以不手动的去配置依赖关系。再看看TestGuice.java。

    TestGuice.java
     

    Java代码
    1. package cn.jcourse.guice.test;   
    2.   
    3. import junit.framework.TestCase;   
    4. import cn.jcourse.guice.HelloGuice;   
    5.   
    6. import com.google.inject.Guice;   
    7. import com.google.inject.Injector;   
    8.   
    9. /**     
    10.  * 测试Guice  
    11.  */  
    12. public class TestGuice extends TestCase {   
    13.     public void testHelloGuice() {   
    14.         //Injector injector = Guice.createInjector(new HelloGuiceModule());   
    15.            
    16.         Injector injector = Guice.createInjector();   
    17.            
    18.         HelloGuice helloGuice = injector.getInstance(HelloGuice.class);   
    19.         helloGuice.sayHello();   
    20.     }   
    21. }  

    可以看出,我们不需要自己去new一个Module了,Guice会根据我们提供的注解自己来配置依赖关系。

    我们运行例子的时候可以看出,它也输出了Hello Guice!到控制台。

     

     

     

    通过 Guice 进行依赖项注入(1)

    本教程是转载教程,目的是让大家了解又一个很强大的依赖注入框架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 及其测试

    Java代码
    1. public class FrogMan {   
    2.   private FrogMobile vehicle = new FrogMobile();   
    3.   public FrogMan() {}   
    4.   // crime fighting logic goes here...   
    5. }   
    6.   
    7. public class FrogManTest extends TestCase {   
    8.  public void testFrogManFightsCrime() {   
    9.     FrogMan hero = new FrogMan();   
    10.     hero.fightCrime();   
    11.     //make some assertions...   
    12.   }   
    13. }  

    似乎一切正常,但在运行测试时出现了如清单 2 所示的异常:

    清单 2. 依赖项出现问题

    Java代码
    1. java.lang.RuntimeException: Refinery startup failure.   
    2.   at HeavyWaterRefinery.<init>(HeavyWaterRefinery.java:6)   
    3.   at FrogMobile.<init>(FrogMobile.java:5)   
    4.   at FrogMan.<init>(FrogMan.java:8)   
    5.   at FrogManTest.testFrogManFightsCrime(FrogManTest.java:10)  

    似乎 FrogMobile 构建了一个 HeavyWaterRefinery,假设我不能在测试中构建其中一个依赖项。当然,我可以在生产环境中实现这一点,但是不能保证能在测试中构建第二个提炼厂(refinery)。在现实生活中,您不可能提炼出氧化氘,但您可以依赖远程服务器和强大的数据库。原理是一样的:这些依赖项很难启动,交互起来也很慢,这使得测试比平时更容易失败。

    输入 DI

    为了避免这个问题,您可以创建一个接口(例如 Vehicle),使 FrogMan 类接受 Vehicle 作为一个构造函数参数,如清单 3 所示:

    清单 3. 依赖接口并注入它们

    Java代码
    1. public class FrogMan {   
    2.   private Vehicle vehicle;   
    3.   
    4.   public FrogMan(Vehicle vehicle) {   
    5.     this.vehicle = vehicle;   
    6.   }   
    7.   // crime fighting logic goes here...   
    8. }  

    这种用法就是 DI 的本质 — 使类通过引用接口而不是构建接口(或使用静态引用)来接受它们的依赖项。清单 4 显示了 DI 如何使测试变得更简单:

    清单 4. 测试可以使用 mock 而不是麻烦的依赖项

    Java代码
    1. static class MockVehicle implements Vehicle {   
    2.   boolean didZoom;   
    3.   
    4.   public String zoom() {   
    5.     this.didZoom = true;   
    6.     return "Mock Vehicle Zoomed.";   
    7.   }   
    8. }   
    9.   
    10. public void testFrogManFightsCrime() {   
    11.   MockVehicle mockVehicle = new MockVehicle();   
    12.   
    13.   FrogMan hero = new FrogMan(mockVehicle);   
    14.   hero.fightCrime();   
    15.   
    16.   assertTrue(mockVehicle.didZoom);   
    17.   // other assertions   
    18. }  

    这个测试使用了一个手动编写的 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

    Java代码
    1. @Inject  
    2. public FrogMan(Vehicle vehicle) {   
    3.   this.vehicle = vehicle;   
    4. }  

    一些工程师不喜欢给类添加 @Inject。他们更喜欢一个完全忽略 DI 框架的类。这种说法有一定道理,但是我不大赞同。依赖项的注入会使注释的作用更加明显。@Inject 标记只在您要求 Guice 构建类时才有意义。如果不要求 Guice 构建 FrogMan,这个注释对代码行为就没有任何影响。这个注释恰当地指出了 Guice 将参与构建类。但是,使用它需要源代码级别的访问。如果这个注释带来不便,或者正在使用 Guice 创建无法控制其源代码的对象,那么 Guice 就会用一个替代机制。

    告诉 Guice 您需要哪个依赖项

    Guice 知道您的 hero 需要一个 Vehicle 后,它需要知道提供什么 Vehicle。清单 6 包含一个 Module:一个特殊的类,用于告诉 Guice 各个接口对应的实现。

    清单 6. HeroModule 将 Vehicle 绑定到 FrogMobile

    Java代码
    1. public class HeroModule implements Module {   
    2.   public void configure(Binder binder) {   
    3.     binder.bind(Vehicle.class).to(FrogMobile.class);   
    4.   }   
    5. }  

    模块就是一个具有某种单实例对象方法的接口。Guice 传递给模块的 Binder 用于告诉 Guice 您想如何构造对象。绑定程序 API 形成一种 区域特定语言。这种小语言允许您编写表达式代码,比如 bind(X).to(Y).in(Z)。后面将提供更多有关绑定程序作用的例子。每次调用 bind 都会创建一个绑定,Guice 将使用绑定集解析注入请求。

    使用 Injector 启动

    然后,使用 Injector 类启动 Guice。通常需要尽早在程序中创建注入器。这样 Guice 能够帮助您创建大部分对象。清单 7 包含一个以 Injector 开始的示例 main 程序:

    清单 7 使用 Injector 启动应用程序

    Java代码
    1. public class Adventure {   
    2.   public static void main(String[] args){   
    3.     Injector injector = Guice.createInjector(new HeroModule());   
    4.     FrogMan hero = injector.getInstance(FrogMan.class);   
    5.     hero.fightCrime();   
    6.   }   
    7. }  

    为了获取注入器,需要在 Guice 类上调用 createInjector。向 createInjector 传递一个模块列表,用于配置它本身(本例只有一个,但您可以添加一个配置 evildoer 的 VillainModule)。拥有注入器后,使用 getInstance 向它请求对象,传递您想返回的 .class(细心的读者会注意到您不需要告诉 Guice 有关 FrogMan 的信息。如果您请求一个具体类,而它有一个 @Inject 构造函数或公共非参数构造函数的话,Guice 就会创建这个类,而无需调用 bind)。

    这是 Guice 构造对象的第一种方式:显式询问。但是,您不会希望在启动例程之外使用这个操作。更好、更简单的方式是让 Guice 注入依赖项、依赖项的依赖项,依此类推(正如谚语所说:“背起地球的海龟站在另一个海龟的背上”)。最初看来,这似乎比较麻烦,但您很快就会习惯这种用法。例如,清单 8 显示了一个注入了 FuelSource 的 FrogMobile:

    清单 8. FrogMobile 接受一个 FuelSource

    Java代码
    1. @Inject  
    2. public FrogMobile(FuelSource fuelSource){   
    3.   this.fuelSource = fuelSource;   
    4. }  

    这意味着,当您检索 FrogMan 时,Guice 会构建一个 FuelSource、一个 FrogMobile,最后是一个 FrogMan。即使应用程序与注入器只交互一次,也是如此。

    当然,您并不总是有机会控制应用程序的 main 例程。例如,许多 Web 框架自动构建 “操作”、“模板” 或其他一些初始服务。总是可以找到一个地方插入 Guice,不管是使用该框架的一个插件,还是使用一些自己手动编写的代码(例如,Guice 项目发布了一个 Struts 2 插件,它允许 Guice 配置您的 Strut 操作)。

     

     

    通过 Guice 进行依赖项注入(2)

     

    其他注入形式

    到目前为止,我展示了 @Inject 应用于构造函数的用法。当 Guice 找到注释时,它会挑选构造函数参数,并试图为每个参数找到一个配置绑定。这称为 构造函数注入。根据 Guice 的最佳实践指南,构造函数注入是询问依赖项的首选方式。但这不是唯一的方式。清单 9 显示了配置 FrogMan 类的另一种方式:

    清单 9. 方法注入

    Java代码
    1. public class FrogMan{   
    2.   private Vehicle vehicle;   
    3.   
    4.   @Inject  
    5.   public void setVehicle(Vehicle vehicle) {   
    6.     this.vehicle = vehicle;   
    7.   }   
    8. //etc. ...  

    注意,我没有使用注入的构造函数,而是改用一个带有 @Inject 标记的方法。Guice 会在构造好 hero 之后立即调用此方法。Spring 框架的忠实用户可以将此方法视为 “setter 注入”。不过,Guice 只关心 @Inject;您可以任意命名这个方法,它可以带有多个参数。此方法可以是包保护的,也可以是私有方法。

    如果您认为 Guice 访问私有方法不是很好,可以参见清单 10,其中 FrogMan 使用了字段注入:

    清单 10. 字段注入

    Java代码
    1. public class FrogMan {   
    2.   @Inject private Vehicle vehicle;   
    3.   public FrogMan(){}   
    4. //etc. ...  

    同样,所有 Guice 都只关心 @Inject 注释。字段注入查找注释的所有字段并试图注入相应的依赖项。

    哪种方法最好

    三个 FrogMan 版本都展示了相同的行为:Guice 在构建时注入相应的 Vehicle。不过,像 Guice 的作者一样,我更喜欢构造函数注入。下面简单分析这三种方式:

    • 构造函数注入 很简单。因为 Java 技术能保证构造函数调用,您不用担心出现未初始化的对象 — 不管是不是由 Guice 创建的。您还可以将字段标记为 final。
    • 字段注入 会影响可测试性,特别是将字段标记为 private 时。这破坏了使用 DI 的主要目的。应该尽量少使用字段注入。
    • 方法注入 在您不控制类的实例化时很有用。如果您有一个需要某些依赖项的超类,也可以使用方法注入(构造函数注入会使这种情况变得很复杂)。

    选择实现

    现在,假设应用程序中有多个 Vehicle。一样英勇的 Weasel Girl 无法驾驭 FrogMobile!同时,您不想在 WeaselCopter 上硬编码依赖项。清单 11 显示了 Weasel Girl 请求一种更快的传输模式:

    清单 11. 使用注释请求某种特定的实现

    Java代码
    1. @Inject  
    2. public WeaselGirl(@Fast Vehicle vehicle) {   
    3.   this.vehicle = vehicle;   
    4. }  

    在清单 12 中,HeroModule 使用绑定函数告诉 Guice WeaselCopter 是 “很快” 的:

    清单 12. 告诉 Guice Module 中的相关注释

    Java代码
    1. public class HeroModule implements Module {   
    2.  public void configure(Binder binder) {   
    3.     binder.bind(Vehicle.class).to(FrogMobile.class);   
    4.     binder.bind(Vehicle.class).annotatedWith(Fast.class).to(WeaselCopter.class);   
    5.   }   
    6. }  

    注意,我选择了一个注释,描述我想以抽象形式描述的工具种类(@Fast),而不是与实现太接近的注释(@WeaselCopter)。如果您使用的注释将想要的实现描述得太精确,就让读者觉得创建一个隐式依赖项。如果使用 @WeaselCopter,而且 Weasel Girl 借用了 Wombat Rocket,就会对程序员阅读和调试代码造成混淆。

    要创建 @Fast 注释,需要复制清单 13 中的模板:

    清单 13. 复制粘贴这段代码以创建一个绑定注释

    Java代码
    1. @Retention(RetentionPolicy.RUNTIME)   
    2. @Target({ElementType.FIELD, ElementType.PARAMETER})   
    3. @BindingAnnotation  
    4. public @interface Fast {}  

    如果您编写了大量 BindingAnnotations,就会得到许多这样的小文件,每个文件只是注释名称不同。如果您觉得这很繁琐,或者需要执行快速的原型设计,可以考虑 Guice 的内置 @Named 注释,它接受一个字符串属性。清单 14 展示了这种替代方法:

    清单 14. 使用 @Named 代替自定义注释

    Java代码
    1. // in WeaselGirl   
    2. @Inject  
    3. public WeaselGirl(@Named("Fast") Vehicle vehicle) {   
    4.   //...   
    5. }   
    6.   
    7. // in HeroModule   
    8. binder.bind(Vehicle.class)   
    9.   .annotatedWith(Names.named("Fast")).to(WeaselCopter.class);  

    这种方法是可行的,但由于名称只在字符串内有效,所以这不能利用编译时检查和自动补齐。总的来说,我更愿意自己编写注释。

    如果您根本不想使用注释,怎么办?即使添加 @Fast 或 @Named("Fast") 都会使类在某种程度上影响配置本身。如果想知道如何解决这个问题,请接着阅读。

    provider 方法

    如果每次探险都派遣 Frog Man,您可能会厌烦。您喜欢在每个场景中出现的 hero 是随机的。但是,Guice 的默认绑定程序 API 不允许出现 “每次调用时将 Hero 类绑定到一个不同的实现” 这样的调用。不过,您可以 告诉 Guice 使用一种特殊的方法来创建每个新的 Hero。清单 15 显示了将一个新方法添加到 HeroModule 中,并用特殊的 @Provides 注释进行注释:

    清单 15. 使用 provider 编写自定义创建逻辑

    Java代码
    1. @Provides  
    2. private Hero provideHero(FrogMan frogMan, WeaselGirl weaselGirl) {   
    3.   if (Math.random() > .5) {   
    4.     return frogMan;   
    5.   }   
    6.   return weaselGirl;   
    7. }  

    Guice 会自动发现具有 @Provides 注释的 Module 中的所有方法。根据 Hero 的返回类型,在您请求某个 hero 时,Guice 会进行计算,它应该调用 provider 方法来提供 hero。您可以为 provider 方法添加逻辑以构建对象并在缓存中查询它,或者通过其他方式获得它。provider 方法是将其他库集成到 Guice 模块中的很好方式。它们也是从 Guice 2.0 开始提供的新方法(Guice 1.0 中只编写自定义 provider 类,这比较乏味,而且更加繁琐。如果您已经决定使用 Guice 1.0,用户指南中有这种旧方法的文档,而且在本文随附的 示例