Lombok!代碼精簡化神器還是代碼“亞健康”的元兇?

點擊上方“Java精選”,選擇“設爲星標”

別問別人爲什麼,多問自己憑什麼!

下方留言必回,有問必答!

每天 08:00 更新文章,每天進步一點點...

如果您正在閱讀此文,想必您對Project Lombok已經有了一段時間的瞭解。您是否正準備擁抱Lombok?還是正準備將如此酷炫的項目推薦給你的團隊?如果您準備那麼做,不妨聽聽我在使用Lombok一年後的一些感受。

我承認,Lombok是一個很不錯的Java庫,它可以讓你在少寫代碼的同時耍耍酷,簡單的幾個註解,就可以幹掉一大片模板代碼。但是,所有的源代碼很多時候是用來閱讀的,只有很少的時間是用來執行的(你可以細品這句話)。

一年以前,我和大多數人都認爲Lombok的出現會讓Java的編碼體驗會更好,並極力的在我的團隊中推薦使用Lombok。一年以後,我開始對此產生顧慮,尤其是在我準備爲開源的博客系統Una-Boot升級Java版本時,我才意識到Lombok自己掉入了一個戲法陷阱。在我進一步分析其源代碼並理解相關注解的工作原理後,發現我並不需要使用一個非標準的第三方庫將Java轉換爲一個精巧而酷炫的語言。引入Lombok讓我的項目一時爽,但一時爽的代價是隨着項目推進,技術債務開始累積。

接下來,我將用幾個大家耳熟能詳的場景,重演自己是如何掉入Lombok的戲法陷阱。

愛的開始,恨的起源

面對Lombok提供的諸多“神走位”,你並不會介意在IDE上新增一個插件。對於IntelliJ IDEA玩家而言,只需搜索“Lombok Plugin”便可找到這款神器並安裝上它。愛上Lombok從安裝Lombok插件開始,恨也從此萌芽。

沒使用Lombok之前,我們的源代碼看起來是這一的:

public class MyObject{private Long id;private String name;private int age;private int gender;

public Long getId(){return id;}public void setId(Long id){this.id = id;}public String getName(){return name;}public void setName(String name){this.name = name;}public int getAge(){return age;}public void setAge(int age){this.age = age;}public int getGender(){return gender;}public void setGender(int gender){this.gender = gender;}

@Overridepublic boolean equals(Object o){if(this == o){return true;}if(o == null || getClass() != o.getClass()){return false;}MyObject obj = (MyObject) o;return age = obj.age &&gender = obj.gender &&Objects.equals(id,obj.id) &&Objects.queals(name,obj.name);}

@Overridepublic int hashCode(){return Objects.hash(id,name,age,gender);}

@Overridepublic String toString(){return "MyObject{"+"id="+id+"name="+name+"age="+age+"gender="+gander+"}";}}

每個JavaBean都會充斥着如上述getter,setter,equals,hashCode和toString的模板代碼,這看起來像一個偏胖的人(不得不承認Java是一個有缺陷的編程語言)。當我們安裝好Lombok插件後,IDE便可以識別其酷炫的註解,使用Lombok的@Getter和@Setter註解後,代碼會像下面這樣看起來很苗條:

@Getter@Setterpublic class MyObject{private Long id;private String name;private int age;private int gender;

@Overridepublic boolean equals(Object o){if(this == o){return true;}if(o == null || getClass() != o.getClass()){return false;}MyObject obj = (MyObject) o;return age = obj.age &&gender = obj.gender &&Objects.equals(id,obj.id) &&Objects.queals(name,obj.name);}

@Overridepublic int hashCode(){return Objects.hash(id,name,age,gender);}

@Overridepublic String toString(){return "MyObject{"+"id="+id+"name="+name+"age="+age+"gender="+gander+"}";}}

你以爲Lombok就這點能耐?它還能讓你代碼的“身材”更苗條,更魔鬼。上面的代碼仍然還有改進的空間,我們可以用@EqualsAndHashCod註解替換到equals和hashCode方法:

@Getter@Setter@EqualsAndHashCodepublic class MyObject{private Long id;private String name;private int age;private int gender;

@Overridepublic String toString(){return "MyObject{"+"id="+id+"name="+name+"age="+age+"gender="+gander+"}";}}

現在的代碼是否看起來爽多了?但這還不是最爽的時候。既然其他方法都替換掉了,那把toString方法也一起拿掉吧.如你所願,可以使用@ToString註解去掉對於的方法:

@Getter@Setter@EqualsAndHashCode@ToStringpublic class MyObject{private Long id;private String name;private int age;private int gender;}

經過Lombok的戲法之後,相比一開始的代碼,看起來是不是很酷炫,很苗條,很性感?你以爲到此爲止了?遠不止於此。你會發現類名上一大坨註解看起來好彆扭,Lombok提供了一個組合註解,可以替換掉類名頭上那坨像翔一樣的東西:

@Datapublic class MyObject{private Long id;private String name;private int age;private int gender;}

現在,Lombok是否讓你的對象成爲了你心目中完美的樣子?魔鬼的“身材”,酷炫精煉。Lombok還有其他一些註解,如@Slf4j,@NoArgsConstructor,@AllArgsConstructor等等,介紹Lombok用法不是本文重點。

以上代碼行數的變化過程,也許是無數程序員愛上Lombok的主要原因吧,這就像一個肥胖的人逐漸變成一個身材苗條的人。同時也讓你看到了一個現象:你以爲程序員很懶嗎?其他有些時候他們比你想象中的還要懶。在爽的同時,也爲代碼種下了禍根。

曲的審美,愛的隱患

扭曲的審美,導致了被審視的對象出於亞健康狀態。使用Lombok插件之後,我們的代碼也處於“亞健康”狀態。還是迴歸一開始的那句話:所有的源代碼很多時候是用來閱讀的,只有很少的時間是用來執行的。

本質上講,我們都追求減少程序中的樣板代碼以使其代碼更精煉簡潔,從而提高代碼的可讀性和可維護性。但Lombok並沒有達到我們所追求的這一願景,它僅僅是利用Java語言在編譯時的空檔期,使用一種很取巧的方式,將我們所需要的方法注入(寫入)到當前的類中,這種過程很像在hack我們的代碼,只是一種看起來酷炫的把戲。這種把戲並不智能和安全,反而會破壞Java代碼現有的特性以及代碼的可讀性。下面,結合我自己使用Lombok之後的感受,談談Lombok帶來的幾大痛點。

1. JDK版本問題

當我想要將現有項目的JDK從Java 8升級到Java 11時,我發現Lombok不能正常工作了。於是我不得不將所有的Lombok註解從項目源代碼中清除,並使用IDE自帶的功能生成getter/setter,equals,hashCode,toString以及構造器等方法,你也可以使用Delombok工具完成這一過程。但這終究會消耗你很多的時間。

2. 脅迫使用

當你的源代碼中使用了Lombok,恰好你的代碼又被其他的人所使用,那麼依賴你代碼的人,也必須安裝Lombok插件(不管他們喜不喜歡),同時還要花費時間去了解Lombok註解的使用情況,如果不那麼做,代碼將無法正常運行。使用過Lombok之後,我發現這是一種很流氓的行爲。

3. 可讀性差

Lombok隱藏了JavaBean封裝的細節,如果你使用註解,它將提供一個巨型構造器,讓外界有機會在初始化對象時修改類中所有的屬性。首先,這是極其不安全的,因爲類中某系屬性我們是不希望被修改的;另外,如果某個類中有幾十個屬性存在,就會有一個包含幾十個參數的構造器被Lombok注入到類中,這是不理智的行爲;其次,構造器參數的順序完全由Lombok所控制,我們並不能操控,只有當你需要調試時才發現有一個奇怪的“小強”在等着你;最後,在運行代碼之前,所有JavaBean中的方法你只能想象他們長什麼樣子,你並不能看見。

4. 代碼耦合度增加

當你使用Lombok來編寫某一個模塊的代碼後,其餘依賴此模塊的其他代碼都需要引入Lombok依賴,同時還需要在IDE中安裝Lombok的插件。雖然Lombok的依賴包並不大,但就因爲其中一個地方使用了Lombok,其餘所有的依賴方都要強制加入Lombok的Jar包,這是一種入侵式的耦合,如果再遇上JDK版本問題,這將是一場災難。

5. 得不償失

使用Lombok,一時覺得很爽,但它卻污染了你的代碼,破壞了Java代碼的完整性,可讀性和安全性,同時還增加的團隊的技術債務,這是一種弊大於利,得不償失的操作。如果你確實想讓自己的代碼更加精煉,同時又兼顧可讀性和編碼效率,不妨使用主流的Scala或Kotlin這一基於JVM的語言。

總結

Lombok本身是一個優秀的Java代碼庫,它採用了一種取巧的語法糖,簡化了Java的編碼,爲Java代碼的精簡提供了一種方式,但在使用此代碼庫時,需要了解到Lombok並非一個標準的Java庫。使用Lombok,會增加團隊的技術債務,降低代碼的可讀性,增大代碼的耦合度和調式難度。雖然在一定程度上Lombok減少了樣板代碼的書寫,但也帶來了一些未知的風險。如果你正在參與一個團隊項目(或大型項目),考慮到後續的升級與擴展,是否使用Lombok,請與你的團隊多溝通和三思。

期往精選 點擊標題可跳轉

- 小程序,3000+ 道面試題在線刷,最新、最全 Java 面試題!

文章有幫助的話,在看,轉發吧!