作为一名资深后端开发,为什么从不推荐别人使用Lombok,谈谈我的看法...
@Date:加在类上,相当于同时使用了@ToString、@EqualsAndHashCode、@Getter、@Setter和@RequiredArgsConstrutor这些注解,但是提供的 getter、setter 方法都是 public 的
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导入方式如下:
<dependency>
<groupId>org.projectlombok</groupId>
<artifactId>lombok</artifactId>
<version>1.18.12</version>
<scope>provided</scope>
</dependency>
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的态度是很模糊的,优缺点都很清楚,秉承“不使用就不会有问题”的观点,所以我自己不使用,也不会主动推荐给别人使用。
我是IT无知君,您的点赞、评论和关注,是我继续创作的不懈动力。
学无止境,气有浩然,让我们一起加油,天涯未远,江湖有缘再见!!
开放原子开发者工作坊旨在鼓励更多人参与开源活动,与志同道合的开发者们相互交流开发经验、分享开发心得、获取前沿技术趋势。工作坊有多种形式的开发者活动,如meetup、训练营等,主打技术交流,干货满满,真诚地邀请各位开发者共同参与!
更多推荐
所有评论(0)