在 Java語言中,有大量類似于 getter、setter、toString 這樣的模板代碼,為了解決這個問題,一個流行的框架 Lombok誕生了。前幾天看到騰訊的一道 2面題:Lombok是銀彈?還是陷阱?生產環境建議使用 Lombok嗎?今天我們一起來聊一聊。
Lombok是一個三方開源的 Java庫,通過注解可以自動將代碼插入到編輯器和構建工具中,為 Java程序員省略了很多樣板代碼的編寫,除了生成getter、setter方法,還可以生成 equals、hashCode和各種類構造函數等。在很多 Java程序員的眼中簡直就是銀彈。
Lombok的使用很簡單,主要是通過注解來精簡代碼,常用的注解如下:
下面給出了一個 Lombok @Data注解的使用示例:
import lombok.Data; @Datapublic class User { private String id; private String name;}
上述示例通過在類上使用 @Data注解后,我們就不需要再手動添加 getter、setter等模版代碼,整個代碼看起來簡潔了很多。
從 Lombok如何使用的講解中我們可以看到:Lombok主要是依賴注解來標識(標記)需要在該類中生成哪些代碼。除此之外,還有一個重要的技術點是抽象語法樹(AST)。
抽象語法樹(AST,Abstract Syntax Tree)是一種用于表示程序源代碼結構的樹狀數據結構。它抽象出代碼的語法結構,忽略某些細節,以便于編譯器或解釋器進行分析和處理。
在 Java中,AST是一種在生成字節碼之前創建的中間結構,如下圖為 AST示例:
Lombok是注解和 AST的完美組合,Lombok通過識別注解,然后操縱 AST將不存在的樣板代碼插入到類中。
但是 Lombok并不是直接修改源代碼文件,而是在編譯過程中動態生成代碼,為了實現這一點,Lombok需要攔截 Java編譯器的調用,而這種攔截是通過插件來實現的,比如 IntelliJ, VSCode, Eclipse 或者在構建工具 Maven, Gradle, Make等。因此,如果選用的 IDE或依賴/構建管理器不支持 Lombok,代碼將無法編譯。
Lombok為 Java省略了很多樣板代碼的編寫,但是,對于項目中使用 Lombok,我們還是應該多一些思考,這里主要總結為下面 4個考慮點:
由于 Lombok在編譯時完成樣板代碼的填充,因此,勢必導致編譯時間的增加,尤其是在大型代碼庫中,這種增加可能會有很大影響,盡管 Lombok隨著版本的升級,性能也在提升,但使用 Lombok的時間仍然比不使用 Lombok的時間長。
Lombok大大減少了Java類中的樣板代碼,特別是在領域類(TOs、DTOs、實體)中,這些類通常有很多類級別的屬性。
但是,使用 Lombok后,所有參與這個項目開發的技術人員都需要安裝 Lombok插件,因此,對于不愿意使用 Lombok的開發人員來說不太友好。另外,如果團隊中有剛工作的組員,如果一開始就在 Lombok這種環境下,那么對于他們的成長也是不友好的。
在開發過程中,我們通常會使用 IDE或構建工具自動編譯Java代碼,所以 Lombok可以在這個階段自動完成它的工作,但是,假如我們只是使用 javac來編譯源代碼,如果源代碼中使用了 Lombok生成的get方法,這種情況下編譯會出錯提示get方法不存在。
如果項目中涉及 JDK的版本升級,可能出現兼容性問題,因為每個版本可能會改變 AST的生成和解釋方式。因此,如果使用了 Lombok,在升級 Java版本后,可能會導致項目無法編譯。
盡管這個問題重新編譯后可以解決,但是,如果使用了 Lombok,還是要注意上述提到的可能編譯失敗的問題。
Lombok 是在編譯期為類生成樣板代碼,因此,開發人員在調試時看不到這些代碼,可能會給調試帶來一些困難,另外,Lombok 自動生成的代碼是隱式的,可能會讓代碼行為不夠透明,給代碼審查和維護帶來一些挑戰。
本文從面試題出發,講解了 Lombok的工作原理以及其優點和需要考慮的因素:
可以大大減少樣板代碼的手動編寫
對于我個人而言,傾向于在項目不使用 Lombok,主要有以下 3個原因:
最后,項目中是否使用 Lombok,取決于個人喜好以及團隊和項目的選擇(大廠一般都會禁用 Lombok),但是,上述的考慮因素或許可以給你的決策多一個參考。
本文鏈接:http://www.tebozhan.com/showinfo-26-94843-0.html騰訊電商二面:Lombok 是銀彈?還是陷阱?
聲明:本網頁內容旨在傳播知識,若有侵權等問題請及時與本網聯系,我們將在第一時間刪除處理。郵件:2376512515@qq.com