Lombok!代码简洁神器还是代码“亚健康”元凶?
共 10478字,需浏览 21分钟
·
2021-09-12 15:39
如果您正在阅读此文,想必您对Project Lombok已经有了一段时间的了解。您是否正准备拥抱Lombok?还是正准备将如此酷炫的项目推荐给你的团队?如果您准备那么做,不妨听听我在使用Lombok一年后的一些感受。
我承认,Lombok是一个很不错的Java库,它可以让你在少写代码的同时耍耍酷,简单的几个注解,就可以干掉一大片模板代码。但是,所有的源代码很多时候是用来阅读的,只有很少的时间是用来执行的(你可以细品这句话)。
一年以前,我和大多数人都认为Lombok的出现会让Java的编码体验会更好,并极力的在我的团队中推荐使用Lombok。一年以后,我开始对此产生顾虑,尤其是在我准备为开源的博客系统Una-Boot升级Java版本时,我才意识到Lombok自己掉入了一个戏法陷阱。在我进一步分析其源代码并理解相关注解的工作原理后,发现我并不需要使用一个非标准的第三方库将Java转换为一个精巧而酷炫的语言。引入Lombok让我的项目一时爽,但一时爽的代价是随着项目推进,技术债务开始累积。
接下来,我将用几个大家耳熟能详的场景,重演自己是如何掉入Lombok的戏法陷阱。
爱的开始,恨的起源
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
public Long getId(){
return id;
}
public void setId(Long id){
this.id = id;
}
public String getName(){
return name;
}
public void setName(String name){
this.name = name;
}
public int getAge(){
return age;
}
public void setAge(int age){
this.age = age;
}
public int getGender(){
return gender;
}
public void setGender(int gender){
this.gender = gender;
}
@Override
public boolean equals(Object o){
if(this == o){
return true;
}
if(o == null || getClass() != o.getClass()){
return false;
}
MyObject obj = (MyObject) o;
return age = obj.age &&
gender = obj.gender &&
Objects.equals(id,obj.id) &&
Objects.queals(name,obj.name);
}
@Override
public int hashCode(){
return Objects.hash(id,name,age,gender);
}
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
}
每个JavaBean都会充斥着如上述getter,setter,equals,hashCode和toString的模板代码,这看起来像一个偏胖的人(不得不承认Java是一个有缺陷的编程语言)。当我们安装好Lombok插件后,IDE便可以识别其酷炫的注解,使用Lombok的@Getter
和@Setter
注解后,代码会像下面这样看起来很苗条:
@Getter
@Setter
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
@Override
public boolean equals(Object o){
if(this == o){
return true;
}
if(o == null || getClass() != o.getClass()){
return false;
}
MyObject obj = (MyObject) o;
return age = obj.age &&
gender = obj.gender &&
Objects.equals(id,obj.id) &&
Objects.queals(name,obj.name);
}
@Override
public int hashCode(){
return Objects.hash(id,name,age,gender);
}
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
}
你以为Lombok就这点能耐?它还能让你代码的“身材”更苗条,更魔鬼。上面的代码仍然还有改进的空间,我们可以用@EqualsAndHashCod
注解替换到equals和hashCode方法:
@Getter
@Setter
@EqualsAndHashCode
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
@Override
public String toString(){
return "MyObject{"+
"id="+id+
"name="+name+
"age="+age+
"gender="+gander+
"}";
}
}
@ToString
注解去掉对于的方法:@Getter
@Setter
@EqualsAndHashCode
@ToString
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
}
@Data
,可以替换掉类名头上那坨像翔一样的东西:@Data
public class MyObject{
private Long id;
private String name;
private int age;
private int gender;
}
以上代码行数的变化过程,也许是无数程序员爱上Lombok的主要原因吧,这就像一个肥胖的人逐渐变成一个身材苗条的人。同时也让你看到了一个现象:你以为程序员很懒吗?其他有些时候他们比你想象中的还要懒。在爽的同时,也为代码种下了祸根。
扭曲的审美,爱的隐患
扭曲的审美,导致了被审视的对象出于亚健康状态。使用Lombok插件之后,我们的代码也处于“亚健康”状态。还是回归一开始的那句话:所有的源代码很多时候是用来阅读的,只有很少的时间是用来执行的。
本质上讲,我们都追求减少程序中的样板代码以使其代码更精炼简洁,从而提高代码的可读性和可维护性。但Lombok并没有达到我们所追求的这一愿景,它仅仅是利用Java语言在编译时的空档期,使用一种很取巧的方式,将我们所需要的方法注入(写入)到当前的类中,这种过程很像在hack我们的代码,只是一种看起来酷炫的把戏。这种把戏并不智能和安全,反而会破坏Java代码现有的特性以及代码的可读性。下面,结合我自己使用Lombok之后的感受,谈谈Lombok带来的几大痛点。
1. JDK版本问题
2. 胁迫使用
当你的源代码中使用了Lombok,恰好你的代码又被其他的人所使用,那么依赖你代码的人,也必须安装Lombok插件(不管他们喜不喜欢),同时还要花费时间去了解Lombok注解的使用情况,如果不那么做,代码将无法正常运行。使用过Lombok之后,我发现这是一种很流氓的行为。
3. 可读性差
@AllArgsConstructor
注解,它将提供一个巨型构造器,让外界有机会在初始化对象时修改类中所有的属性。首先,这是极其不安全的,因为类中某系属性我们是不希望被修改的;另外,如果某个类中有几十个属性存在,就会有一个包含几十个参数的构造器被Lombok注入到类中,这是不理智的行为;其次,构造器参数的顺序完全由Lombok所控制,我们并不能操控,只有当你需要调试时才发现有一个奇怪的“小强”在等着你;最后,在运行代码之前,所有JavaBean中的方法你只能想象他们长什么样子,你并不能看见。4. 代码耦合度增加
5. 得不偿失
总结
正文结束
1.不认命,从10年流水线工人,到谷歌上班的程序媛,一位湖南妹子的励志故事
5.37岁程序员被裁,120天没找到工作,无奈去小公司,结果懵了...
一个人学习、工作很迷茫?
点击「阅读原文」加入我们的小圈子!