我已经阅读了关于Google Guice的文章,并了解了其他依赖注入方法存在的一般问题,但是我还没有看到有人在实践中使用Guice的例子,以便更加清楚地了解其价值所在。
我想知道是否有人知道这样的例子?
使用Google Guice来提供单元测试的便利只是一个高级别的优点。有些人甚至在他们的项目中都不使用单元测试。人们一直在使用Spring/依赖注入,而不仅仅是用于单元测试。
使用Google Guice的低级别优势是关于应用程序内的内聚性问题,你的项目中的类之间可以松散耦合。我可以为另一个类提供一个类,而它们彼此之间并不依赖。
考虑以下示例:
public class A {
}
public class B {
A a = new A();
}
B类将与A类紧密耦合,换句话说,它依赖于A类的存在。
但使用Guice,我可以这样使其松散耦合:
public class B {
private A a;
@Inject
public B(A a) {
this.a = a;
}
}
现在,类B
与A
松耦合,Guice负责提供A
的实例而不是B
必须去实例化它。通过这种方式,您可以将其扩展为提供A
接口给B
,如果您想对应用程序进行单元测试,则实现可以是模拟对象。
话虽如此,我们仅讨论了依赖注入的好处。除了依赖注入之外,使用Google Guice的好处包括:
@Inject
注释即可。这是其中的概述。但是,随着您深入了解Guice,还有更多非常好的东西。一个简单的现实生活示例是,如果您正在使用MVP实现的GWT,则GWT应用程序中的组件/小部件之间耦合度非常低且不紧密集成在一起。
因为谷歌在关键任务应用中运行Guice(几乎每个基于Java的应用程序也是Guice应用程序:AdWords、Google Docs、Gmail,甚至是YouTube,如“疯狂”的Bob Lee在Guice²中所报告的),我不相信Guice完全错误且没有提供任何价值。可悲的是,我认为谷歌不会提供这些应用程序的大量代码作为示例……但您可以在使用Guice的应用程序列表和/或第三方Guice插件列表中找到有趣的东西。或者查看Guice²中提到的书籍。或者问问Bob :)
我认为编写接口、测试和代理是有优势的。
编写接口可以帮助保持代码分层,使得可以注入模拟对象进行测试,并且可以自动生成代理,这样客户端代码就不需要关心实现细节。
这对于Guice、Spring、PicoContainer以及所有DI框架都适用。
简明扼要吗?
B
不再与A
耦合,但似乎你提到的唯一优势是现在你可以为测试提供模拟对象。对我来说,B
仍然与A
耦合,但它不再负责实际构造实例。 - Koray Tugay