依賴注入及AOP簡述（七）——FQCN請求模式

標籤：style   io   color   os   使用   sp   strong   on   div   

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);

依賴注入及AOP簡述（七）——FQCN請求模式