作为一名资深后端开发，为什么从不推荐别人使用Lombok，谈谈我的看法...

Lombok是一款非常实用Java第三方工具，它可以帮助开发人员消除Java的冗长代码，尤其是对于简单的Java对象（POJO）。

Lombok在给我们带来便利的同时，也带来了不小的隐患。

鉴于自己踩过的许多坑，所以我从不主动推荐别人使用Lombok，但是，也并不会干涉他人使用。并且，因为我身边有些同事的代码还是使用了的，所以我也被迫的要安装Lombok的插件。

以上就是我对Lombok的态度。既然聊到这个话题，我们也来分析下Lombok的特点：

1、Lombok的使用

1.1 IDE中安装Lombok插件

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

在IDEA中安装方式如下:

File → Settings → Plugins，输入“lombok”，选中“install”进行安装即可，安装后需重启IDEA才能运行。

1.2 导入相关依赖

Lombok 支持使用多重构建工具进行导入依赖，目前主要支持maven、gardle、ant等均支持。

如使用maven导入方式如下：

    org.projectlombok
    lombok
    1.18.12
    provided

1.3 代码中使用注解

Lombok精简代码的方式主要是通过注解来实现，其中常用的有@Data、@Getter/@Setter、@Builder、@NonNull等。

如使用@Data注解，即可简单的定义一个Java Bean：

import lombok.Data;

@Data
public class User {
    private String id;
    private String age;
    private String name;
    private String job;
}

使用@Data注解在类上，这样一来，这个实体类中的属性就不需要get，set和toString方法了，这对于POJO类十分有用。

1.4 注释的含义

• @Date：加在类上，相当于同时使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor这些注解；
• @AllArgsConstructor：加在类上，可以生成含实体类全参数的构造方法；
• @NoArgsConstructor：加在类上，可以生成无参构造方法；
• @RequiredArgsConstructor：加在类上，配合@NonNull注解使用，生成指定参数的构造方法。比如在age属性前面加@NonNull注解，则User生成需要age参数的构造方法；
• @Getter：加在类上，可以生成实体类所有属性的getter方法；
• @Setter：加在类上，可以生成实体类所有属性的setter方法；
• @ToString：加在类上，调用toString()方法，可以输出实体类中所有属性的值。
   

2、Lombok有什么好处？

通过上面的例子，大家可以发现，使用@Data注解大大减少了代码量，使代码非常简洁，这也是很多开发者热衷于使用Lombok的主要原因。

不仅如此，我还列举了Lombok其它的优势：

• 减少模板代码：.lombok处理get，set，toString，hash，equal等方法，大量的模板代码进行封装，减少重复代码，当增加新属性的时候，以上方法都不需要再重新编写；
• 增强代码可读性：专注于类的属性定义，不需要再去为排版浪费时间；
• 减少代码维护：新增属性的时候，会减少非常多的代码维护工作。

3、Lombok有什么坏处？

既然我从不主动推荐别人使用Lombok，那一定是踩过许多坑的经验之谈。

所以，接下来我们重点说一下Lombok在使用过程中会带来哪些问题。

3.1 强迫队友

Lombok插件的使用，要求开发者一定要在IDE中安装对应的插件。不仅自己要安装，任何和你协同开发的人都要安装。

如果有谁未安装插件的话，使用IDE打开一个基于Lombok的项目的话会提示找不到方法等错误，导致项目编译失败。

更重要的是，如果我们定义的一个jar包中使用了Lombok，那么就要求所有依赖这个jar包的所有应用都必须安装插件，这种侵入性是很高的。

只次一点，我就已经决定不在自己的代码中使用Lombok注解了，但是，为了项目编译我依然会使用Lombok插件。

3.2 代码可调试性降低

Lombok确实可以帮忙减少很多代码，因为Lombok会帮忙自动生成很多代码。

但是，这些代码是要在编译阶段才会生成的，所以在开发的过程中，其实很多代码其实是缺失的。

这就给代码调试带来一定的问题，我们想要知道某个类中的某个属性的getter方法都被哪些类引用的话，就没那么简单了。

3.3 影响版本升级

Lombok对于代码有很强的侵入性，就可能带来一个比较大的问题，那就是会影响我们对JDK的升级。

按照如今JDK的升级频率，每半年都会推出一个新的版本，但是Lombok作为一个第三方工具，并且是由开源团队维护的，那么他的迭代速度是无法保证的。

所以，如果我们需要升级到某个新版本的JDK的时候，若其中的特性在Lombok中不支持的话就会受到影响。

还有一个可能带来的问题，就是Lombok自身的升级也会受到限制。

因为一个应用可能依赖了多个jar包，而每个jar包可能又要依赖不同版本的Lombok，这就导致在应用中需要做版本仲裁，而我们知道，jar包版本仲裁是没那么容易的，而且发生问题的概率也很高。

3.4 谈谈踩过的坑

在使用Lombok过程中，如果对于各种注解的底层原理不理解的话，很容易产生意想不到的结果。

举一个简单的例子：

我们知道，当我们使用@Data定义一个类的时候，会自动帮我们生成equals()方法 。

但是如果只使用了@Data，而不使用@EqualsAndHashCode(callSuper=true)的话，会默认是@EqualsAndHashCode(callSuper=false)，这时候生成的equals()方法只会比较子类的属性，不会考虑从父类继承的属性，无论父类属性访问权限是否开放，这就可能得到意想不到的结果。

3.5 可能会破坏封装性

如果说上面的4点问题都可以人为避免，那么，关于封装性的问题就是Lombok的短板了。

举个简单的例子，我们定义一个购物车类：

@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三个属性。

4、总结

Lombok注解可以自动生成代码，大大减少了代码量，使代码非常简洁。

但是并不意味着Lombok的使用没有任何问题，在使用Lombok的过程中，还可能存在对队友不友好、对代码不友好、对调试不友好、对升级不友好等问题。

虽然，使用Lombok还会导致破坏封装性的问题，但是我更认为Lombok的操作是遵循了Bean的使用初衷。

Bean尤其数据库和Java类的映射Bean，Java对Bean的定义和使用就是无参数的构造方法和set和get方法，而不应该在bean中处理任何和业务有任何关系的逻辑。

总结下来，我对Lombok的态度是很模糊的，优缺点都很清楚，秉承“不使用就不会有问题”的观点，所以我自己不使用，也不会主动推荐给别人使用。

 

少侠请留步 ... ヾ(◍°∇°◍)ﾉﾞ ... 
欢迎点赞、评论、加关注，让更多人看到学到赚到
更多精彩，请关注我的"今日头条号"：Java云笔记