在 Java语言中,有大量类似于 getter、setter、toString 这样的模板代码,为了解决这个问题,一个流行的框架 Lombok诞生了。前几天看到腾讯的一道 2面题:Lombok是银弹?还是陷阱?生产环境建议使用 Lombok吗?今天我们一起来聊一聊。
Lombok是一个三方开源的 Java库,通过注解可以自动将代码插入到编辑器和构建工具中,为 Java程序员省略了很多样板代码的编写,除了生成getter、setter方法,还可以生成 equals、hashCode和各种类构造函数等。在很多 Java程序员的眼中简直就是银弹。
Lombok的使用很简单,主要是通过注解来精简代码,常用的注解如下:
下面给出了一个 Lombok @Data注解的使用示例:
import lombok.Data; @Datapublic class User { private String id; private String name;}
上述示例通过在类上使用 @Data注解后,我们就不需要再手动添加 getter、setter等模版代码,整个代码看起来简洁了很多。
从 Lombok如何使用的讲解中我们可以看到:Lombok主要是依赖注解来标识(标记)需要在该类中生成哪些代码。除此之外,还有一个重要的技术点是抽象语法树(AST)。
抽象语法树(AST,Abstract Syntax Tree)是一种用于表示程序源代码结构的树状数据结构。它抽象出代码的语法结构,忽略某些细节,以便于编译器或解释器进行分析和处理。
在 Java中,AST是一种在生成字节码之前创建的中间结构,如下图为 AST示例:
Lombok是注解和 AST的完美组合,Lombok通过识别注解,然后操纵 AST将不存在的样板代码插入到类中。
但是 Lombok并不是直接修改源代码文件,而是在编译过程中动态生成代码,为了实现这一点,Lombok需要拦截 Java编译器的调用,而这种拦截是通过插件来实现的,比如 IntelliJ, VSCode, Eclipse 或者在构建工具 Maven, Gradle, Make等。因此,如果选用的 IDE或依赖/构建管理器不支持 Lombok,代码将无法编译。
Lombok为 Java省略了很多样板代码的编写,但是,对于项目中使用 Lombok,我们还是应该多一些思考,这里主要总结为下面 4个考虑点:
由于 Lombok在编译时完成样板代码的填充,因此,势必导致编译时间的增加,尤其是在大型代码库中,这种增加可能会有很大影响,尽管 Lombok随着版本的升级,性能也在提升,但使用 Lombok的时间仍然比不使用 Lombok的时间长。
Lombok大大减少了Java类中的样板代码,特别是在领域类(TOs、DTOs、实体)中,这些类通常有很多类级别的属性。
但是,使用 Lombok后,所有参与这个项目开发的技术人员都需要安装 Lombok插件,因此,对于不愿意使用 Lombok的开发人员来说不太友好。另外,如果团队中有刚工作的组员,如果一开始就在 Lombok这种环境下,那么对于他们的成长也是不友好的。
在开发过程中,我们通常会使用 IDE或构建工具自动编译Java代码,所以 Lombok可以在这个阶段自动完成它的工作,但是,假如我们只是使用 javac来编译源代码,如果源代码中使用了 Lombok生成的get方法,这种情况下编译会出错提示get方法不存在。
如果项目中涉及 JDK的版本升级,可能出现兼容性问题,因为每个版本可能会改变 AST的生成和解释方式。因此,如果使用了 Lombok,在升级 Java版本后,可能会导致项目无法编译。
尽管这个问题重新编译后可以解决,但是,如果使用了 Lombok,还是要注意上述提到的可能编译失败的问题。
Lombok 是在编译期为类生成样板代码,因此,开发人员在调试时看不到这些代码,可能会给调试带来一些困难,另外,Lombok 自动生成的代码是隐式的,可能会让代码行为不够透明,给代码审查和维护带来一些挑战。
本文从面试题出发,讲解了 Lombok的工作原理以及其优点和需要考虑的因素:
可以大大减少样板代码的手动编写
对于我个人而言,倾向于在项目不使用 Lombok,主要有以下 3个原因:
最后,项目中是否使用 Lombok,取决于个人喜好以及团队和项目的选择(大厂一般都会禁用 Lombok),但是,上述的考虑因素或许可以给你的决策多一个参考。
本文链接:http://www.28at.com/showinfo-26-94843-0.html腾讯电商二面:Lombok 是银弹?还是陷阱?
声明:本网页内容旨在传播知识,若有侵权等问题请及时与本网联系,我们将在第一时间删除处理。邮件:2376512515@qq.com