IDEA使用@Autowired注解為什么會提示不建議?
眾所周知,Spring框架提供了三種可選的依賴注入方式:構造器注入、Setter方法注入和Field注入。在此,我們將詳細探討這三種注入方式的使用場景。
構造器注入
如下所示,在使用構造器注入時,我們可以將屬性字段設置為final。通過構造器注入,當對AService進行實例化時,BService對象必須提前初始化完成,從而確保被注入的對象一定不為null。構造器注入適用于對象之間存在強依賴關系的場景,但無法解決循環依賴問題(因為必須互相依賴對方初始化完成,從而產生沖突,無法解決)。
關于循環依賴問題,推薦閱讀
Setter 方法注入
使用Setter方法進行注入時,Spring會在執行默認的無參構造函數實例化Bean對象后,調用Setter方法來注入依賴。這種方式下,我們可以將”required”屬性設置為false,表示如果注入的Bean對象不存在,Spring會直接跳過注入,而不會報錯。
Field注入
的確,Field注入在視覺上非常簡潔美觀,因此被廣泛采用。使用Field注入時,Spring容器會在對象實例化完成之后,通過反射機制來設置需要注入的字段。
為什么IDEA不推薦使用Field注入
經查閱多方資料,我找到了以下幾個重要原因,導致Field注入可能不太被推薦使用:
- 可能導致空指針異常:如果對象創建不使用Spring容器,而是直接使用無參構造方法new一個對象,此時使用注入的對象可能導致空指針異常。
- 不能使用final修飾字段:缺乏final修飾會使得類的依賴可變,進而可能引發一些不可預料的異常。通常情況下,可以使用構造方法注入來聲明強制依賴的Bean,使用Setter方法注入來聲明可選依賴的Bean。
- 可能更容易違反單一職責原則:這是一個關鍵原因。使用字段注入可能會輕易地在類中引入各種依賴,導致類的職責過多,但開發者往往難以察覺。相比之下,使用構造方法注入,當構造方法的參數過多時,會提示開發者重構這個類。
- 不利于寫單元測試:在單元測試中,使用Field注入,必須使用反射的方式來Mock依賴對象。
為了解決這些問題,我們可以采用以下替代方案:
- 當類有強依賴于其他Bean時,優先使用構造方法注入。
- 對于可選依賴,可以使用Setter方法注入,并在代碼中處理可能出現的引用對象不存在的情況。
Spring官方的態度
Spring官方文檔在依賴注入這一節中的確沒有明確討論字段注入這種方式,而更加強調了構造方法注入和Setter方法注入。構造方法注入被視為首選的依賴注入方式,因為它可以確保依賴的對象在創建時就被注入,從而避免了一些潛在的問題,比如空指針異常和類的可變性。
Setter方法注入在可選依賴的場景下也很有用,但需要開發者自行處理依賴對象不存在的情況。
總的來說,Spring團隊強烈推薦使用構造方法注入,因為它在很多方面都更加安全和可靠。同時,選擇適當的依賴注入方式也可以根據具體情況靈活使用。
總結
在Spring中使用依賴注入時,首選構造方法注入。雖然構造方法注入無法解決循環依賴問題,但當循環依賴出現時,我們應該優先考慮是否代碼結構設計存在問題。當然,也不排除某些必須使用循環依賴的場景,此時字段注入可能會派上用場。
最后,我想強調的是,在平時使用IDEA的過程中,關注代碼下劃線或飄黃的提醒是很重要的。這些提示可以幫助我們學習他人總結的最佳實踐經驗,提升自己的代碼水平。
本文首發:
感謝支持!
?

浙公網安備 33010602011771號