[TOC]

关于lombok插件的争议

https://zhuanlan.zhihu.com/p/146659383

https://blog.csdn.net/weixin_38405253/article/details/111829077

一、lombok是啥

那么lombok到底是个什么呢,lombok是一个可以通过简单的注解的形式来帮助我们简化消除一些必须有但显得很臃肿的 Java 代码的工具,简单来说,比如我们新建了一个类,然后在其中写了几个字段,然后通常情况下我们需要手动去建立getter和setter方法啊,构造函数啊之类的,lombok的作用就是为了省去我们手动创建这些代码的麻烦,它能够在我们编译源码的时候自动帮我们生成这些方法。

lombok能够达到的效果就是在源码中不需要写一些通用的方法,但是在编译生成的字节码文件中会帮我们生成这些方法,这就是lombok的神奇作用。

虽然有人可能会说IDE里面都自带自动生成这些方法的功能,但是使用lombok会使你的代码看起来更加简洁,写起来也更加方便。

从前我们的pojo类都是这样的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
/**
* 日历表单
* @author xia17
* @since 2021/8/18 14:21
*/
public class CalendarForm extends Form {

/** 年份 */
private Integer year;

/** 待修改的日期 */
private List<Calendar> list;


public Integer getYear() {
return year;
}

public void setYear(Integer year) {
this.year = year;
}

public List<Calendar> getList() {
return list;
}

public void setList(List<Calendar> list) {
this.list = list;
}
}

使用lombok后它是这样的

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
/**
* 日历表单
* @author xia17
* @since 2021/8/18 14:21
*/
@Getter
@Setter
public class CalendarForm extends Form {

/** 年份 */
private Integer year;

/** 待修改的日期 */
private List<Calendar> list;
}

两套代码实现的功能是一样的,无疑lombok的看起来更简单。

二、网上不推荐使用lombok的原因

随便在网上一找都有很多原因,在这里例举下。

2.1 jdk版本问题

当我想要将现有项目的JDK从Java 8升级到Java 11时,我发现Lombok不能正常工作了。于是我不得不将所有的Lombok注解从项目源代码中清除,并使用IDE自带的功能生成getter/setter,equals,hashCode,toString以及构造器等方法,你也可以使用Delombok工具完成这一过程。但这终究会消耗你很多的时间。

2. 2 胁迫使用

当你的源代码中使用了Lombok,恰好你的代码又被其他的人所使用,那么依赖你代码的人,也必须安装Lombok插件(不管他们喜不喜欢),同时还要花费时间去了解Lombok注解的使用情况,如果不那么做,代码将无法正常运行。使用过Lombok之后,我发现这是一种很流氓的行为。

2.3 可读性差

Lombok隐藏了JavaBean封装的细节,如果你使用@AllArgsConstructor注解,它将提供一个巨型构造器,让外界有机会在初始化对象时修改类中所有的属性。首先,这是极其不安全的,因为类中某系属性我们是不希望被修改的;另外,如果某个类中有几十个属性存在,就会有一个包含几十个参数的构造器被Lombok注入到类中,这是不理智的行为;其次,构造器参数的顺序完全由Lombok所控制,我们并不能操控,只有当你需要调试时才发现有一个奇怪的“小强”在等着你;最后,在运行代码之前,所有JavaBean中的方法你只能想象他们长什么样子,你并不能看见。

2.4 代码耦合度增加

当你使用Lombok来编写某一个模块的代码后,其余依赖此模块的其他代码都需要引入Lombok依赖,同时还需要在IDE中安装Lombok的插件。虽然Lombok的依赖包并不大,但就因为其中一个地方使用了Lombok,其余所有的依赖方都要强制加入Lombok的Jar包,这是一种入侵式的耦合,如果再遇上JDK版本问题,这将是一场灾难。

2.5 强制队友安装对应编辑器的lombok插件

这点确实比较恶心,因为如果使用lombok注解编写代码,就要求参与开发的所有人都必须安装lombok插件,否则代码编译出错。

而且在早期,lombok不是idea的自带插件,会存在更新了新版idea , 然后lombok插件还未更新而用不了的情况,导致要退回idea版本。

三、为什么我依然推荐使用lombok

记 得lombok是在学校的时候学习 springboot 时了解到的,当时一经接触就完全沉迷进去了一只用到现在,导致现在在写个没有使用spring的老乡们,没有依赖lombok实在是很难受。

现在先反驳下上面说的不推荐使用lombok原因。

3.1 jdk版本问题

实际上项目升级jdk版本的需求很难见到,不是大众需求。升级后导致lombok不能使用,那为什么不考虑换个lombok版本呢 ?

对于这个jdk版本问题,网上是有解决方案的,换个lombok版本就好了。

为什么还要去修改代码呢 ?

3.2 胁迫使用

都1202年了,不会还有人不知道lombok吧 ?lombok的使用是很简单的,就那么几个注解,会需要花费很多时间学习吗?

再说如果开发团队确定了使用了某项技术, 作为团队的一员肯定是要了解这么技术的。何谈胁迫使用呢?

3.3 可读性差

这个我个人觉得可读性提高了呀,只有属性的类,看起来不比你看那堆含有 大量getter。setter 的代码好看 ?

假如有人偷偷的给你在某个setter里面加上一个逻辑,你也能一眼观察到吗 ?

3.4 代码耦合度增加

如果你这个项目是打包给其他项目使用的话,另一个项目完全没有使用lombok的必须性,lombok在打成jar包后就没有在使用了。

lombok会在你编译后class文件中 生成 getter settter方法。

3.5 强制队友安装对应编辑器的lombok插件

装个插件很难吗 ?

如果你使用idea的话,那么lombok插件已经和 git , maven等插件一样是官方内置插件了。

可见,lombok的使用率已经很广泛了。

四、推荐使用Lombok

强力推荐新项目使用lombok。