新來個技術總監，禁止咱們使用Lombok！

我有個學弟，在一家小型互聯網公司作Java後端開發，最近他們公司新來了一個技術總監，這位技術總監對技術細節很看重，一來公司以後就推出了不少"政策"，好比定義了不少開發規範、日誌規範、甚至是要求你們統一使用某一款IDE。

可是這些都不是我這個學弟和我吐槽的點，他真正和我吐槽的是，他很不能理解，這位新來的技術總監居然禁止公司內部全部開發使用Lombok。可是又沒給出十分明確的，可讓人信服的理由。

因而他來找我聊天，問我這個要求究竟是否合理。關於這個事情，我認爲這位技術總監的出發點是好的，可是作法未免有些極端。

之因此說出發點是好的，是由於使用Lombok確實會帶來不少問題，並且我我的在工做中也基本不主動使用。

之因此說不主動使用，那是由於有些同事的代碼仍是使用了的，因此我也被迫的要安裝Lombok的插件。

既然聊到這個話題，就簡單說說個人一些見解。

Lombok有什麼好處？

Lombok是一款很是實用Java工具，可用來幫助開發人員消除Java的冗長代碼，尤爲是對於簡單的Java對象（POJO）。它經過註釋實現這一目的。

若是你們對於Lombok比較瞭解的話，能夠先跳過這一段，直接日後看，若是不是很熟悉的話，能夠簡單瞭解一下。

想在項目中使用Lombok，須要三個步驟：

1、IDE中安裝Lombok插件

目前Lombok支持多種IDE，其中包括主流的Eclips、Intellji IDEA、Myeclipse等都是支持的。

在IDEA中安裝方式以下:



2、導入相關依賴

Lombok 支持使用多重構建工具進行導入依賴，目前主要支持maven、gardle、ant等均支持。

如使用maven導入方式以下：

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.12</version>
    <scope>provided</scope>
</dependency>
複製代碼

3、代碼中使用註解

Lombok精簡代碼的方式主要是經過註解來實現，其中經常使用的有@Data、@Getter/@Setter、@Builder、@NonNull等。

如使用@Data註解，便可簡單的定義一個Java Bean：

import lombok.Data;
@Data
public class Menu {
    private String shopId;
    private String skuMenuId;
    private String skuName;
}
複製代碼

使用@Data註解在類上，至關於同時使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor這些註解，對於POJO類十分有用。

即自動幫忙給例子中的Menu類中定義了toString、Getter、Setter等方法。

經過上面的例子，你們能夠發現，咱們是好用@Data註解大大減小了代碼量，使代碼很是簡潔。這也是不少開發者熱衷於使用Lombok的主要緣由。

另外，關於Lombok的使用，不一樣人有不一樣的見解，由於不少人都使用過Lombok，對於他的優勢都比較瞭解，因此接下來咱們重點說一下Lombok的使用會帶來哪些問題。

Lombok有什麼壞處？

強X隊友

由於Lombok的使用要求開發者必定要在IDE中安裝對應的插件。

若是未安裝插件的話，使用IDE打開一個基於Lombok的項目的話會提示找不到方法等錯誤。致使項目編譯失敗。

也就是說，若是項目組中有一我的使用了Lombok，那麼其餘人就必須也要安裝IDE插件。不然就沒辦法協同開發。

更重要的是，若是咱們定義的一個jar包中使用了Lombok，那麼就要求全部依賴這個jar包的全部應用都必須安裝插件，這種侵入性是很高的。

代碼可讀性，可調試性低

在代碼中使用了Lombok，確實能夠幫忙減小不少代碼，由於Lombok會幫忙自動生成不少代碼。

可是這些代碼是要在編譯階段纔會生成的，因此在開發的過程當中，其實不少代碼實際上是缺失的。

在代碼中大量使用Lombok，就致使代碼的可讀性會低不少，並且也會給代碼調試帶來必定的問題。

好比，咱們想要知道某個類中的某個屬性的getter方法都被哪些類引用的話，就沒那麼簡單了。

有坑

由於Lombok使代碼開發很是簡便，這就使得部分開發者對其產生過分依賴。

在使用Lombok過程當中，若是對於各類註解的底層原理不理解的話，很容易產生意想不到的結果。

舉一個簡單的例子，咱們知道，當咱們使用@Data定義一個類的時候，會自動幫咱們生成equals()方法 。

可是若是隻使用了@Data，而不使用@EqualsAndHashCode(callSuper=true)的話，會默認是@EqualsAndHashCode(callSuper=false),這時候生成的equals()方法只會比較子類的屬性，不會考慮從父類繼承的屬性，不管父類屬性訪問權限是否開放。

這就可能獲得意想不到的結果。

影響升級

由於Lombok對於代碼有很強的侵入性，就可能帶來一個比較大的問題，那就是會影響咱們對JDK的升級。

按照現在JDK的升級頻率，每半年都會推出一個新的版本，可是Lombok做爲一個第三方工具，而且是由開源團隊維護的，那麼他的迭代速度是沒法保證的。

因此，若是咱們須要升級到某個新版本的JDK的時候，若其中的特性在Lombok中不支持的話就會受到影響。

還有一個可能帶來的問題，就是Lombok自身的升級也會受到限制。

由於一個應用可能依賴了多個jar包，而每一個jar包可能又要依賴不一樣版本的Lombok，這就致使在應用中須要作版本仲裁，而咱們知道，jar包版本仲裁是沒那麼容易的，並且發生問題的機率也很高。

破壞封裝性

以上幾個問題，我認爲都是有辦法能夠避免的。可是有些人排斥使用Lombok還有一個重要的緣由，那就是他會破壞封裝性。

衆所周知，Java的三大特性包括封裝性、繼承性和多態性。

若是咱們在代碼中直接使用Lombok，那麼他會自動幫咱們生成getter、setter 等方法，這就意味着，一個類中的全部參數都自動提供了設置和讀取方法。

舉個簡單的例子，咱們定義一個購物車類：

@Data
public class ShoppingCart { 
    //商品數目
    private int itemsCount; 
    //總價格
    private double totalPrice; 
    //商品明細
    private List items = new ArrayList<>();
}
//例子來源於《極客時間-設計模式之美》
複製代碼

咱們知道，購物車中商品數目、商品明細以及總價格三者以前實際上是有關聯關係的，若是須要修改的話是要一塊兒修改的。

可是，咱們使用了Lombok的@Data註解，對於itemsCount 和 totalPrice這兩個屬性。雖然咱們將它們定義成 private 類型，可是提供了 public 的 getter、setter 方法。

外部能夠經過 setter 方法隨意地修改這兩個屬性的值。咱們能夠隨意調用 setter 方法，來從新設置 itemsCount、totalPrice 屬性的值，這也會致使其跟 items 屬性的值不一致。

而面向對象封裝的定義是：經過訪問權限控制，隱藏內部數據，外部僅能經過類提供的有限的接口訪問、修改內部數據。因此，暴露不該該暴露的 setter 方法，明顯違反了面向對象的封裝特性。

好的作法應該是不提供getter/setter，而是隻提供一個public的addItem方法，同時取修改itemsCount、totalPrice以及items三個屬性。

總結

本文總結了經常使用的Java開發工具Lombok的優缺點。

優勢是使用註解便可幫忙自動生成代碼，大大減小了代碼量，使代碼很是簡潔。

可是並不意味着Lombok的使用沒有任何問題，在使用Lombok的過程當中，還可能存在對隊友不友好、對代碼不友好、對調試不友好、對升級不友好等問題。

最重要的是，使用Lombok還會致使破壞封裝性的問題。

雖然使用Lombok存在着不少方便，可是也帶來了一些問題。

可是到底建不建議在平常開發中使用，我其實保持一箇中立的態度，不建議你們過分依賴，也不要求你們必定要完全不用。

只要你們在使用的過程當中，或者評估要不要在代碼中引入Lombok以前，在想到他的優勢的同時，可以考慮到他給代碼帶來的問題的，那麼本文的目的也就達到了！

參考資料：

time.geekbang.org/column/arti…

projectlombok.org/