2.2. FQCN请求模式
为了弥补纯字符串请求模式中的类型安全问题，全类名（FQCN）请求模式就应运而生了。其思想便是，在向容器请求依赖对象的时候，不是通过字符串的标识符、而是通过被请求的依赖的全类名来定位依赖。这样如果开发者误将全类名标识符写错的话，在编译时立即会提醒“类不存在”。并且，如果使用Eclipse等IDE开发工具的话，用其提供的自动完整代码的功能就会轻松地将依赖的全类名标识符定义到代码中。
在第一章的“3.3 依赖注入框架简介”一节中我们提到了Google Guice框架是一个解决了类型安全问题的依赖注入框架，我们来看一段Guice中定义注入点的例子。
public class Depositor {
private Bank bank;
// ……
@Inject // bank的Setter注入点
public void setBank(Bank bank) {
this.bank = bank;
}
// ……
public Cash withDraw(BigDecimal amount) {
return bank.withDraw(depositBook, amount);
}
}
|
|
在Guice框架中，如果使用注解的方式定义注入点，我们可以使用@Inject。当Guice框架去解析这个注解的时候，会将Bank类的实现类自动地设定到注入点。也就是说如果容器中有且只有一个Bank类的实现类，Guice会将其实例化后分发给依赖者。
// Bank的实现类
public class BankICBC implements Bank { // …… }
|
|
但是如果容器中有多个Bank类的实现类，比如还有一个BankCMB的实现类，此时Guice框架就不能正确识别究竟应把哪一个实现的依赖对象提供给依赖者了，这就是全类名请求模式的一个缺陷，即其会将依赖对象的接口限定为只有一个实现，关于这个问题的解决方案我们稍后会在“混合请求模式”中介绍。
在第一章的“3.1 依赖注入的原理”一节中我们讲到，注解并不是声明注入点的唯一方式，如果使用了API方式声明注入点，则Spring、Seam、Guice都有各自的API能够应用这种全类名形式的依赖注入。例如：
// Spring的全类名注入的API
BeanFactory injector = new FileSystemApplicationContext("depositConfiguration.xml")
this.bank = (Bank) injector.getBean(Bank.class);
// Seam的全类名注入的API
this.bank = (Bank) Component.getInstance(BankICBC.class);
// Guice的全类名注入的API
Injector injector = Guice.createInjector();
this.bank = (Bank) injector.getInstance(Bank.class);
|
|
