Lombok的利与弊

使用Lombok

整体定位

没有太多技术上的东西，主要就是减少代码。或者说，将以前写的常用且重复的代码用注解的形式“简写“一下。如给属性添加Setter，Getter方法，无参构造方法，全参构造方法，hashCode()，equals()方法，toString()等等。

import

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.12</version>
</dependency>

常用注解

Lombok features
最常用的有：@Data，@Setter，@Getter，@NoArgsConstructor。
其作用不再赘述了，直接看上面官网文档就知道了。

其他好用的注解

• @Slf4j

作用在类上，可以直接取代：

private static final org.slf4j.Logger log = org.slf4j.LoggerFactory.getLogger(XXX.class);

• @Builder

自动生成建造者模式的方法。

缺点

这位老哥总结的很详细：作为一名资深后端开发，为什么从不推荐别人使用Lombok，谈谈我的看法…
总结一下，有以下几点：

• 侵入性太强
  因为Lombok注解如@Getter（），IDE在代码提示阶段就会报错：stu.getName()找不到该方法，需要下载相应的插件才可以消除错误提示。
  在多人协作开发过程中，如果有一个人使用lombok开发，那么其他人必然也需要装，不然整个项目编译不能成功。
• 代码跟踪不友好
  因为用注解的形式省去了Setter，Getter等方法，在代码跟踪时（如查看Setter的所有调用位置）就会”断链“。
• 版本兼容问题
  私以为这个问题不是那么严重。
  1）和Java的兼容性问题由Java本身的向后兼容性保证。
  2）团队队员之间的lombok应该由父POM统一管理，而不是各个队员自己指定。)
  3）和第三方依赖中的lombok版本冲突问题，属于项目”依赖冲突“的范畴，和任何其他jar包的依赖冲突一样，应该仔细进行依赖审查，exclude掉子依赖的lombok
• 封装性问题
  即使对于private属性，@Data or @Setter注解会生成public的Setter，其实这个问题也不算是问题，看到网上老哥已经给出解决方案

@Setter(AccessLevel.PROTECTED)

即这样生成了private级别的Setter方法，即维持了封装性。

• 不懂误用的问题
  如，不知道@Data是以下三个注解的合成：
  
  来源：lombok的Data注解
  PS：
  1）关于lombok关于构造器的注解，这篇写的挺好《Lombok 实战 —— @NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor》)
  2）其实具体的lombok的作用，大家可以去看编译之后的.class，对比原来的.java就明白到底什么作用了
  回到”不懂误用“的问题，如果使用者不知道Data覆写了hashCode()方法，同时又使用了Set/Map等，就有可能造成严重的后果。

到底用还是不用

知道发生了什么，小而独立的业务项目使用

以上弊端分析可以看到，最大的弊端：

• 不懂注解给类带来了哪些改变，或者说只注意到增加了Setter/Getter/Constructor
• 侵入性太强，绑架队友
• 代码跟踪困难

仔细分析下来，不是不可以用。最重要的一点：不要因为使用一个偷懒工具造成bug，在了解注解给代码带来了什么改变的前提下，小团队（特别个人独立开发项目）是可以用的。

大项目，基础的工具包不要用

如果是大项目，协同的人太多，不合适。
同样地，向外提供的工具包同样不要依赖lombok，虽然在之前的分析中，认为依赖冲突是客户端自己应该解决的问题，但是能不造成麻烦就不要造成，谁也不能保证他们就能正确排包。

实用性的建议

在最简单的Java Bean上使用@Data
在实际使用中，@Data应该是使用最广泛的注解，它的确也带来了很大的便利。如果非要使用的话，建议把它用在最简单的Java Bean上。
1）这个bean的private属性对封装性没有那么高要求（生成public Setter也没事）
2）这个bean对象不会作为Set，Map参数（泛型）传入（因为hashCode()已经被重写，很危险）