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...
}
