通过Guice进行依赖项注入,使用较少模板的可测试代码

Guice 是一个依赖项注入&＃xff08;DI&＃xff09;框架。几年来我一直建议开发人员使用 DI&＃xff0c;因为它提高了可维护性、可测试性和灵活性。通过观察工程师对 Guice 的反馈&＃xff0c;我发现说服程序员去采用一种新技术的最好方法是使这种技术简单易用。Guice 让 DI 变得很简单&＃xff0c;因此 Google 采用了这种方法。我希望本文能帮助您轻松学习 Guice。

介绍而不是争论 Guice 紧跟极富创造力的 DI 框架家族的脚步&＃xff08;即 PicoContainer&＃xff0c;它是有争议的框架之一。它的支持者通过一个页面解释了它的历史和相互关系&＃xff1b;请参阅 参考资料&＃xff09;。Guice 后来者极力争辩哪一个框架更好&＃xff0c;以及是否需要另一个 DI 框架。与任何技术选择一样&＃xff0c;每个库都有它的优点和缺点。我认为 Guice 带来了一些新意&＃xff0c;不过在这篇文章中&＃xff0c;我只是介绍 Guice 的功能&＃xff0c;不会发表任何评论&＃xff08;您可以上网搜索 “guice 对比 spring”&＃xff0c;查看一些活跃的讨论&＃xff09;。

Guice 2.0 beta

在写这篇文章时&＃xff0c;Guice 开发团队正在奋力编写 Guice 2.0&＃xff0c;希望能在 2008 年底之前发布。早期的 beta 发布在 Google 代码下载站点&＃xff08;请参阅 参考资料&＃xff09;。这是一个好消息&＃xff0c;因为 Guice 团队添加了一些新功能&＃xff0c;使 Guice 代码的使用和理解变得更简单。beta 版没有最终版中的一些功能&＃xff0c;但是 beta 很稳定&＃xff0c;质量也很好。事实上&＃xff0c;Google 在产品软件中使用的是 beta 版。我建议您使用 beta 版。这篇文章是专门为 Guice 2.0 编写的&＃xff0c;介绍了 Guice 的一些新功能&＃xff0c;但没有讨论 1.0 中已经废弃的一些功能。Guice 团队向我保证&＃xff1a;这里讨论的功能在最终发行版和当前 beta 版中都是一样的。

如果您已经了解了 DI&＃xff0c;而且知道为什么要借助一个框架来使用 DI&＃xff0c;那么您可以跳到 通过 Guice 进行基本注入 小节。否则&＃xff0c;请继续阅读&＃xff0c;了解 DI 的好处。

DI 案例

我将以一个例子开始。假设我正在编写一个超级英雄&＃xff08;superhero&＃xff09;应用程序&＃xff0c;同时实现一个名为 Frog Man 的 hero&＃xff08;英雄&＃xff09;。清单 1 是相关代码和第一个测试&＃xff08;您一定明白编写单元测试的重要性&＃xff0c;这里就不多说了&＃xff09;。

清单 1. 一个基本 hero 及其测试

public class FrogMan {<br>private FrogMobile vehicle &＃61; new FrogMobile();<br>public FrogMan() {}<br>// crime fighting logic goes here...<br>}<br>public class FrogManTest extends TestCase {<br>public void testFrogManFightsCrime() {<br>FrogMan hero &＃61; new FrogMan();<br>hero.fightCrime();<br>//make some assertions...<br>}<br>}<br>

似乎一切正常&＃xff0c;但在运行测试时出现了如清单 2 所示的异常&＃xff1a;

清单 2. 依赖项出现问题

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

输入 DI

为了避免这个问题&＃xff0c;您可以创建一个接口&＃xff08;例如 Vehicle&＃xff09;&＃xff0c;使 FrogMan 类接受 Vehicle 作为一个构造函数参数&＃xff0c;如清单 3 所示&＃xff1a;

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

public class FrogMan {<br>private Vehicle vehicle;<br>public FrogMan(Vehicle vehicle) {<br>this.vehicle &＃61; vehicle;<br>}<br>// crime fighting logic goes here...<br>}<br>

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

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

static class MockVehicle implements Vehicle {<br>boolean didZoom;<br>public String zoom() {<br>this.didZoom &＃61; true;<br>return "Mock Vehicle Zoomed.";<br>}<br>}<br>public void testFrogManFightsCrime() {<br>MockVehicle mockVehicle &＃61; new MockVehicle();<br>FrogMan hero &＃61; new FrogMan(mockVehicle);<br>hero.fightCrime();<br>assertTrue(mockVehicle.didZoom);<br>// other assertions<br>}<br>

这个测试使用了一个手动编写的 mock 对象来替换 FrogMobile。DI 不仅在测试中省去了麻烦的 refinery 启动过程&＃xff0c;而且使测试不用了解 FrogMobile 具体细节。需要的仅是一个 Vehicle 接口。除了使测试变得更简单之外&＃xff0c;DI 还有助于提高代码的总体模块性和可维护性。现在&＃xff0c;如果想将 FrogMobile 切换为 FrogBarge&＃xff0c;可以不修改 FrogMan。所有 FrogMan 都依赖于 Vehicle 接口。

不过这里有一个陷阱。如果您是第一次阅读 DI&＃xff0c;可能会想&＃xff1a;“这下好了&＃xff0c;现在所有 FrogMan 的调用方 都必须知道 FrogMobile&＃xff08;refinery、refinery 的依赖项&＃xff0c;依此类推……&＃xff09;”。但如果是这样&＃xff0c;DI 就永远不会这么流行。您可以不增加调用方的负担&＃xff0c;而是编写一些工厂 来管理对象及其依赖项的创建。

工厂是存放框架的地方。工厂需要大量冗长重复的代码。工厂往往会让程序员&＃xff08;和读者&＃xff09;很痛苦&＃xff0c;他们甚至会嫌它麻烦而放弃编写。Guice 和其他 DI 框架可作为 “超级工厂”&＃xff0c;您可以通过配置它们来构建对象。配置 DI 框架比自己编写工厂容易得多。因此&＃xff0c;程序员编写的代码大部分是 DI 样式的。测试越多代码就越好&＃xff0c;程序员以后也就越省事。

通过 Guice 进行基本注入

我希望在我的介绍之后&＃xff0c;您会相信 DI 能为您的设计增加价值&＃xff0c;而且使用框架会使工作更轻松。现在让我们从 &＃64;Inject 注释和模块开始深入讨论 Guice。

告诉 Guice 给类添加 &＃64;Inject

FrogMan 与 Guice 上的 FrogMan 之间的唯一区别是 &＃64;Inject。清单 5 显示了 FrogMan 带有注释的构造函数&＃xff1a;

清单 5. FrogMan 已经加上 &＃64;Inject

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

告诉 Guice 您需要哪个依赖项

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

清单 6. HeroModule 将 Vehicle 绑定到 FrogMobile

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

使用 Injector 启动

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

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

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

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

清单 8. FrogMobile 接受一个 FuelSource

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

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

其他注入形式

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

清单 9. 方法注入

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

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

清单 10. 字段注入

同样&＃xff0c;所有 Guice 都只关心 &＃64;Inject 注释。字段注入查找注释的所有字段并试图注入相应的依赖项。

哪种方法最好

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

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

选择实现

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

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

在清单 12 中&＃xff0c;HeroModule 使用绑定函数告诉 Guice WeaselCopter 是 “很快” 的&＃xff1a;

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

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

要创建 &＃64;Fast 注释&＃xff0c;需要复制清单 13 中的模板&＃xff1a;

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

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

清单 14. 使用 &＃64;Named 代替自定义注释

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

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

provider 方法

provider 方法的其他用法 如果您不放心 Guice 自带的注释&＃xff0c;或者无法使用它们&＃xff08;例如&＃xff0c;您正在创建一个第三方类&＃xff09;&＃xff0c;那么可以使用 provider 方法完美地解决这个问题。因为 provider 方法在模块内有效&＃xff0c;所以可以注释这个方法&＃xff0c;而不用担心其余的源代码会看到注释。例如&＃xff0c;清单 16 包含一个针对 BadgerBoy&＃xff08;一个第三方 hero&＃xff09;的 provider 方法&＃xff1a; 清单 16. provider 方法允许不注释源 &＃64;Provides &＃64;Inject private BadgerBoy provideBadgerBoy(WeaselCopter copter) { return new BadgerBoy(copter); } 通过这种 provider 方法&＃xff0c;您可以使用 Guice 配置 BadgerBoy&＃xff0c;甚至选择它需要的 Vehicle&＃xff0c;这一切操作完全不用更改 BadgerBoy。这意味着您完全可以不使用 &＃64;Inject 或绑定注释&＃xff0c;比如 &＃64;Fast。还可以使用 provider 方法选择依赖项。 选择哪种方法取决于您的喜好&＃xff0c;不管您是否使用第三方类&＃xff0c;或者希望以多紧密的程度将类和它的依赖项联系起来。provider 方法允许自由选择。注释的依赖项允许配置信息更接近类&＃xff0c;这使得源更易于理解&＃xff0c;同时能保持一定的灵活性和可测试性。应用程序可能会根据环境同时使用两种方法来指定依赖项。

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

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

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

在清单 15 中&＃xff0c;Guice 自动使用正确的参数注入 provider 方法。这意味着 Guice 将从它的绑定列表中找到 WeaselGirl 和 FrogMan&＃xff0c;您无需在 provider 方法中手动构建它们。这演示了 “海龟背地球” 原则&＃xff08;海龟背地球&＃xff0c;哪海龟下面是什么呢&＃xff1f;是由另一只海龟背着&＃xff0c;如此反复&＃xff09;。您依靠 Guice 来提供依赖项&＃xff0c;即使是配置 Guice 模块本身。

请求一个 Provider 而不是一个依赖项

假设一个故事&＃xff08;Saga&＃xff09;中要有多个 hero。如果要求 Guice 注入一个 Hero&＃xff0c;只会得到一个 hero。但如果您请求一个 “hero provider”&＃xff0c;就可以根据需要创建任意多的 hero&＃xff0c;如清单 17 所示&＃xff1a;

清单 17. 注入 provider 来控制实例化

public class Saga {<br>private final Provider<Hero> heroProvider;<br>&＃64;Inject<br>public Saga(Provider<Hero> heroProvider) {<br>this.heroProvider &＃61; heroProvider;<br>}<br>public void start() throws IOException {<br>for (int i &＃61; 0; i <3; i&＃43;&＃43;) {<br>Hero hero &＃61; heroProvider.get();<br>hero.fightCrime();<br>}<br>}<br>}<br>

提供者也可以推迟英雄的出场时间&＃xff0c;直到传奇真正开始。如果英雄依赖于时间敏感或上下文敏感的数据&＃xff0c;这就会很方便。

Provider 接口有一个方法&＃xff1a;get。要访问提供的对象&＃xff0c;调用这个方法即可。每次有没有获取新对象以及对象如何配置取决于 Guice 是如何配置的&＃xff08;参阅下面的 作用域 部分&＃xff0c;了解单实例对象和其他长生命周期对象的详细信息&＃xff09;。在本例中&＃xff0c;Guice 使用 &＃64;Provides 方法&＃xff0c;因为它是构建新 Hero 的注册方式。这意味着该传奇应该由任意三位英雄混合而成。

不要把提供者与 provider 方法弄混淆了&＃xff08;在 Guice 1.0&＃xff0c;这两者更难区分开来&＃xff09;。尽管该 Saga 是从自定义 &＃64;Provides 方法中获得它的英雄&＃xff0c;但您可以请求任意 Guice 实例化依赖项的一个 Provider。如果需要&＃xff0c;可以根据清单 18 重新编写 FrogMan 的构造函数&＃xff1a;

清单 18. 请求 Provider 而不是依赖项

&＃xff08;注意您完全不用更改这个模块代码&＃xff09;。重新编写没有任何作用&＃xff1b;只是说明您总是可以请求 Provider&＃xff0c;而不用直接请求依赖项。

作用域

默认情况下&＃xff0c;Guice 为每个请求的依赖项创建一个新实例。如果对象是轻量级的&＃xff0c;这个策略可以很好地工作。但是&＃xff0c;如果有一个创建开销很大的依赖项&＃xff0c;就可能需要在几台客户机之间共享实例。在清单 19 中&＃xff0c;HeroModule 将 HeavyWaterRefinery 作为一个单实例对象绑定&＃xff1a;

清单 19. 将 HeavyWaterRefinery 绑定为一个单实例对象

单实例对象是恶魔吗&＃xff1f; 如果您在网上搜索 “单实例对象是恶魔”&＃xff0c;会找到许多有关单实例对象的帖子、文章和评论。似乎 “应用程序单实例对象” 和 “JVM 单实例对象” 之间存在某种区别&＃xff08;评论员激烈讨论的话题&＃xff09;。JVM 单实例对象通过使用语言技巧强制它的 “单实例对象性质”&＃xff0c;并强制客户机使用静态引用去引用它。另一方面&＃xff0c;应用程序单实例对象不会强制使用这个策略。另外的层级&＃xff08;例如 Guice&＃xff09;会强制要求每个应用程序 存在一个类实例。客户机代码不知道这个规则&＃xff0c;这使得设计非常灵活&＃xff0c;测试也容易编写。

这意味着 Guice 会一直保持 “提炼厂” 可用&＃xff0c;只要另一个实例需要燃料源&＃xff0c;Guice 就会注入相同 的 “提炼厂”。这避免了在应用程序中启动多个 “提炼厂”。

在选择作用域时&＃xff0c;Guice 提供了一个选项。可以使用绑定程序配置它们&＃xff0c;或者直接注释依赖项&＃xff0c;如清单 20 所示&＃xff1a;

清单 20. 改用注释选择作用域

Guice 提供了超出范围的 Singleton 作用域&＃xff0c;但它允许您定义自己的作用域&＃xff08;如果您愿意&＃xff09;。例如&＃xff0c;Guice servlet 包提供了两个其他作用域&＃xff1a;Request 和 Session&＃xff0c;它们为 servlet 请求和 servlet 会话提供类的一个独特实例。

常量绑定和模块配置

HeavyWaterRefinery 需要一个许可密钥才能启动。Guice 可以绑定常量值和新实例。请查看清单 21&＃xff1a;

清单 21. 在模块中绑定常量值

这里有必要使用绑定注释&＃xff0c;否则 Guice 将不能区分不同的 String。

注意&＃xff0c;尽管前面不推荐使用&＃xff0c;我还是选择使用 &＃64;Named 注释。因为我想显示清单 22 所示的代码&＃xff1a;

清单 22. 使用属性文件配置模块

//In HeroModule:<br>private void loadProperties(Binder binder) {<br>InputStream stream &＃61;<br>HeroModule.class.getResourceAsStream("/app.properties");<br>Properties appProperties &＃61; new Properties();<br>try {<br>appProperties.load(stream);<br>Names.bindProperties(binder, appProperties);<br>} catch (IOException e) {<br>// This is the preferred way to tell Guice something went wrong<br>binder.addError(e);<br>}<br>}<br>//In the file app.properties:<br>LicenseKey&＃61;QWERTY1234<br>

这段代码使用 Guice Names.bindProperties 实用函数&＃xff0c;通过恰当的 &＃64;Named 注释将 app.properties 文件中的每个属性与一个常量绑定。这本身就很好&＃xff0c;而且还显示了您可以使模块代码更复杂。如果喜欢&＃xff0c;可以从数据库或 XML 文件加载绑定信息。模块是纯 Java 代码&＃xff0c;这提供了很大的 灵活性。

结束语

Guice 主要概念小结&＃xff1a;

• 使用 &＃64;Inject 请求依赖项。
• 将依赖项与 Module 中的实现绑定。
• 使用 Injector 引导应用程序。
• 使用 &＃64;Provides 方法增加灵活性。

需要了解的 Guice 知识还很多&＃xff0c;但您应该先掌握这篇文章中讨论的内容。我建议下载它&＃xff0c;以及本文的 示例代码。当然&＃xff0c;您也可以创建自己的示例应用程序&＃xff0c;这就更好了。通过示例深入了解概念但又不用考虑生产代码是很有意思的。如果要了解更多 Guice 高级功能&＃xff08;比如面向方面编程支持&＃xff09;&＃xff0c;建议您访问 参考资料 中的一些链接。

说到生产代码&＃xff0c;DI 的一个缺点是它可能感染病毒。注入一个类后&＃xff0c;它会导致注入下一个类&＃xff0c;依此类推。不过这很好&＃xff0c;因为 DI 使代码更好。另一方面&＃xff0c;这需要大量重构现有代码。为了使工作易于管理&＃xff0c;可以将 Guice Injector 存储在某处并直接调用它。应该将这当作一根临时需要的拐杖&＃xff0c;但最后一定可以摆脱它。

Guice 2.0 即将推出。有一些功能我还没有讨论&＃xff0c;它可以使模块的配置更简单&＃xff0c;而且能支持更大、更复杂的配置方案。可以访问 参考资料 中的链接了解即将面世的功能。

我希望您会考虑将 Guice 添加到工具包中。根据我的经验&＃xff0c;DI 对于实现灵活的可测试代码库特别有用。Guice 使 DI 变得简单而有趣。还有什么比容易编写的、灵活的、可测试的代码更好呢&＃xff1f;