依赖注入及AOP简述(六)——字符串请求模式 .
2.?????依賴注入對象的請求模式
前一節我們討論了關于聲明注入點的幾種方法,這一節主要來介紹在注入點上如何定位到所需要的標識符的話題。基本上,我們可以用字符串為標識符來請求依賴對象、或者用全類名(FQCN)為標識符來請求依賴對象、或者用兩者混合的模式。下面我們來依次介紹。
?
2.1.????字符串請求模式
顧名思義,字符串請求模式即依賴注入框架將一個依賴綁定到指定的字符串上,而后將其裝入依賴注入容器。依賴者通過這個字符串,向容器請求所需要的依賴。Seam和Spring都是典型的基于字符串請求模式的框架。
在這樣的模式中,容器中管理的依賴的標識符是通過字符串來定義的,例如我們剛才定義Bank和DepositBook依賴的時候,就是分別將其綁定到了“bank”和“depositBook”這兩個字符串上。
?
|
?
?
?
之后對于依賴者類,只要在注入點上聲明需要請求標識符字符串為“bank”或“depositBook”的依賴,容器就會自動將BankICBC和DepositBookICBC的實例返回給依賴者了。注意前面我們也提到了,Seam框架中在@In注入點缺省是被認為請求與成員變量名同名的依賴,因此下面兩種請求依賴的寫法是一樣的:
?
| |
|
?
?
?
?
?
?
?
?
盡管Seam和Spring都采用了純字符串的標識符定義的模式,但這種模式下有一個很大的弱點:違反了“類型安全(type-safe)”原則,也就是說可能會誤將一個本不是依賴者類所希望的依賴對象注入進來。試想這樣的場景:假設開發者在開發Depositor類并定義其所需要的依賴的時候,誤將“bank”寫成了“bak”,而其他開發者又恰好向容器中注冊了一個標識符為“bak”的依賴。
?
|
?
?
?
?
此時Java編譯器編譯器是不會有任何錯誤信息提示的,因為@In是一個運行時注解,根據Java5的注解原理,運行時注解在編譯時幾乎就相當于一個注釋行被編譯器忽略掉了,只有到了運行時才會由解析它的代碼段產生作用。因此無論是開發者定義成@In(“bak”)還是@In(“bakxxx”)等等,都不會對代碼的編譯造成任何影響。在這個例子中,雖然開發人員誤將“bak”依賴請求進來,但會正常編譯出應用程序,然后在運行這個應用程序的時候則會拋出ClassCastException的異常,這是就需要開發者花力氣去排查錯誤了。
當然如果情況比較簡單的話或許可以很快地排查掉這個bug,但是還有比這更可怕的事情:試想假設Bak類與Bank類是有繼承關系的父子類,那么即使是在運行時也不會拋出ClassCastException的異常,因為依賴可以正確地被cast后set到注入點,這就有可能使得應用程序在被執行了很深之后才出現意想不到的bug,此時再去排查錯誤就會變得很困難了。
當然還有另外一種情況,就是如果容器中沒有“bak”這個依賴的情況。此時聲明注入點處的代碼如果沒有特殊限定,容器很可能將一個null對象設定到注入點,依然只會在運行時拋出NullPointerException異常。NPE異常或許是Java開發者最不愿意看到的異常了,因為它自描述性差,使得開發者經常很難定位錯誤所在。 ?轉載于:https://www.cnblogs.com/Free-Thinker/p/4173276.html
總結
以上是生活随笔為你收集整理的依赖注入及AOP简述(六)——字符串请求模式 .的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 分享一下spark streaming与
- 下一篇: C语言函数参数既做出参又做入参的代表