為什么放棄使用Lombok

這篇文章主要介紹“為什么放棄使用Lombok”，在日常操作中，相信很多人在為什么放棄使用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;     }      @Override     public 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);     }      @Override     public int hashCode(){         return Objects.hash(id,name,age,gender);     }      @Override     public 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 @Setter public class MyObject{     private Long id;     private String name;     private int age;     private int gender;      @Override     public 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);     }      @Override     public int hashCode(){         return Objects.hash(id,name,age,gender);     }      @Override     public String toString(){         return "MyObject{"+             "id="+id+             "name="+name+             "age="+age+             "gender="+gander+             "}";     } }

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

@Getter @Setter @EqualsAndHashCode public class MyObject{     private Long id;     private String name;     private int age;     private int gender;      @Override     public String toString(){         return "MyObject{"+             "id="+id+             "name="+name+             "age="+age+             "gender="+gander+             "}";     } }

經過 Lombok 的戲法之后，相比一開始的代碼，看起來是不是很酷炫，很苗條，很性感?你以為到此為止了?

遠不止于此，你會發現類名上一大坨注解看起來好別扭，Lombok 提供了一個組合注解 @Data，可以替換掉類名頭上那坨像翔一樣的東西：

@Data public 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 帶來的幾大痛點。

JDK 版本問題

當我想要將現有項目的 JDK 從 Java 8 升級到 Java 11 時，我發現 Lombok 不能正常工作了。

于是我不得不將所有的 Lombok 注解從項目源代碼中清除，并使用 IDE 自帶的功能生成  getter/setter，equals，hashCode，toString 以及構造器等方法。

你也可以使用 Delombok 工具完成這一過程，但這終究會消耗你很多的時間。

脅迫使用

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

可讀性差

Lombok 隱藏了 JavaBean 封裝的細節，如果你使用 @AllArgsConstructor  注解，它將提供一個巨型構造器，讓外界有機會在初始化對象時修改類中所有的屬性。

首先，這是極其不安全的，因為類中某系屬性我們是不希望被修改的;另外，如果某個類中有幾十個屬性存在，就會有一個包含幾十個參數的構造器被 Lombo  k注入到類中，這是不理智的行為。

其次，構造器參數的順序完全由 Lombok 所控制，我們并不能操控，只有當你需要調試時才發現有一個奇怪的“小強”在等著你。

最后，在運行代碼之前，所有 JavaBean 中的方法你只能想象他們長什么樣子，你并不能看見。

代碼耦合度增加

當你使用 Lombok 來編寫某一個模塊的代碼后，其余依賴此模塊的其他代碼都需要引入 Lombok 依賴，同時還需要在 IDE 中安裝 Lombok  的插件。

雖然 Lombok 的依賴包并不大，但就因為其中一個地方使用了 Lombok，其余所有的依賴方都要強制加入 Lombok 的 Jar  包，這是一種入侵式的耦合，如果再遇上 JDK 版本問題，這將是一場災難。

得不償失

使用 Lombok，一時覺得很爽，但它卻污染了你的代碼，破壞了 Java  代碼的完整性，可讀性和安全性，同時還增加的團隊的技術債務，這是一種弊大于利，得不償失的操作。

如果你確實想讓自己的代碼更加精煉，同時又兼顧可讀性和編碼效率，不妨使用主流的 Scala 或 Kotlin 這一基于 JVM 的語言。

到此，關于“為什么放棄使用Lombok”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！