最近发现几个大号都在转载一篇《Lombok是让你代码处于“亚健康”状态的真正元凶》的文章,特意仔细阅读了该文,文中的观点基本上都不敢苟同,个人还是会坚持使用Lombok,除非发现一些安全和性能方面的问题。

不清楚大号转载此文是因为没仔细审阅文章内容,还是其他别的原因,但还是有必要写一篇文章表达自己的看法。至于读者是否喜欢Lombok插件,是否在实践中使用,看完本篇文章之后可根据自己的喜好和情况而定。

Lombok是什么鬼?

很多程序员都在抱怨“Java太啰嗦”或有太多的“繁文缛节”。Java语言架构师Brian Goetz也曾在一篇文章中提到:开发人员想要创建纯数据载体类(plain data carriers)通常都必须编写大量低价值、重复的、容易出错的代码。如:构造函数、getter/setter、equals()、hashCode()以及toString()等。

语言本身的问题,很难通过一两个版本能够解决,到JDK14才推出类似Lombok的Record功能。而Lombok便是一款解决上述问题的IDE插件。

在使用Lombok的过程中首先需要IDE安装对应插件,然后pom文件中引入对应依赖,依赖的scope可设为provided的。

Lombok精简代码的方式主要是通过注解来实现,其中常用的有@Data、@Getter/@Setter、@Builder、@NonNull等。如使用@Data注解,即可简单的定义一个Java Bean:

@Data
public class Order {
    private int id;
    private String orderNo;
    private int amount;
}

通过@Data,在IDE在编译时会为该类的属性提供getter/setter方法、equals方法、hashcode方法和toString方法等。

反编译之后,我们可以看到这样一个类:

public class Order {
    private int id;
    private String orderNo;
    private int amount;

    public Order() {
    }

    public int getId() {
        return this.id;
    }

    public String getOrderNo() {
        return this.orderNo;
    }

    public int getAmount() {
        return this.amount;
    }

    public void setId(final int id) {
        this.id = id;
    }

    public void setOrderNo(final String orderNo) {
        this.orderNo = orderNo;
    }

    public void setAmount(final int amount) {
        this.amount = amount;
    }

    public boolean equals(final Object o) {
        if (o == this) {
            return true;
        } else if (!(o instanceof Order)) {
            return false;
        } else {
            Order other = (Order)o;
            if (!other.canEqual(this)) {
                return false;
            } else if (this.getId() != other.getId()) {
                return false;
            } else {
                Object this$orderNo = this.getOrderNo();
                Object other$orderNo = other.getOrderNo();
                if (this$orderNo == null) {
                    if (other$orderNo == null) {
                        return this.getAmount() == other.getAmount();
                    }
                } else if (this$orderNo.equals(other$orderNo)) {
                    return this.getAmount() == other.getAmount();
                }

                return false;
            }
        }
    }

    protected boolean canEqual(final Object other) {
        return other instanceof Order;
    }

    public int hashCode() {
        int PRIME = true;
        int result = 1;
        int result = result * 59 + this.getId();
        Object $orderNo = this.getOrderNo();
        result = result * 59 + ($orderNo == null ? 43 : $orderNo.hashCode());
        result = result * 59 + this.getAmount();
        return result;
    }

    public String toString() {
        return "Order(id=" + this.getId() + ", orderNo=" + this.getOrderNo() + ", amount=" + this.getAmount() + ")";
    }
}

关于其他Lombok功能和注解不再多说,如果想了解可读一读相关文章。上面的实例只是展示Lombok在开发过程中带来的便利之处。下面看看那篇文章中说到的Lombok的不足之处,看你在实践的过程中是否可以忍耐,以及笔者的看法。

观点一:代码是用来阅读的

文中提到:“所有的源代码很多时候是用来阅读的,只有很少的时间是用来执行的。”

上面的说法完全赞同。但说因为使用了Lombok影响了阅读,这个就不敢苟同。

对照一下上面Order实体类的例子,感觉一下哪个更具有可读性?难道不是直接干净利索的展示属性更可读吗?

针对这一项,文中还提到Lombok隐藏了JavaBean封装的细节。如果说将通常普通的getter/setter的细节隐藏了,就算是隐藏细节了,这也太小看Java工程师了。而且,如果需要自定义的特殊的方法,可以完全自行覆盖实现。

文中还提到使用@AllArgsConstructor注解,如果参数多会生成一个巨型的构造方法。说实话,太牵强了,谁没事会生成一个巨型的构造方法呢?就是让你手写代码,你会生成吗?既然不会你干嘛在参数多的时候使用这个注解呢?适合的才是最好的,拿一个不适合使用作为反例,太牵强。

再说回到隐藏细节和可读性上,JDK14提供了Record特性,来看看Record特性的使用。

public record CustUser(
        String firstName,
        String lastName,
        Address address,
        int age
) {}

上面代码便声明了一个Record类型的类,它编译后的效果如下:

public final class CustUser extends java.lang.Record {
    private final java.lang.String firstName;
    private final java.lang.String lastName;
    private final com.flydean.records.Address address;
    private final int age;

    public CustUser(java.lang.String firstName, java.lang.String lastName, com.flydean.records.Address address, int age) { /* compiled code */ }

    public java.lang.String toString() { /* compiled code */ }

    public final int hashCode() { /* compiled code */ }

    public final boolean equals(java.lang.Object o) { /* compiled code */ }

    public java.lang.String firstName() { /* compiled code */ }

    public java.lang.String lastName() { /* compiled code */ }

    public com.flydean.records.Address address() { /* compiled code */ }

    public int age() { /* compiled code */ }
}

是不是很眼熟?对的,它的效果几乎可以完美替代Lombok的功能。JDK14本身都开始往这个方向上发展了,提供了类似的语法糖效果。我们现在有什么理由不使用提供同样功能的Lombok呢?

JDK版本问题

文中提到:JDK从Java8升级到Java11时,发现Lombok不能正常工作……

Lombok可能有这样的问题,但这样的问题不是普通的问题吗?任何一个框架包括主流的SpringBoot框架,你将JDK大跨度的修改,肯定是会出现问题的。但如果是实战项目,哪家公司会搞这么高风险的事?概率太小,而且即便发生也不仅仅是Lombok一个框架会出问题。

由于Lombok是开源的,对最新版本会有一定的滞后性,如果你的项目一直处于变更最新JDK版本,那真不适用。

胁迫使用

这个的确如此,在同一个项目当中,如果一个开发者使用Lombok,那么其他的开发者都必须使用。

但就个人而言,一个项目统一使用相同的规范,相同环境,相同的IDE本来不就是应该的吗?

团队统一规范本来就是提升效率的有效手段。如果一个团队,一个人使用Eclipse,一个人使用IDEA,一个人使用文本编辑(这个牛人)来写代码。

试想一下,你去帮同事排查一个bug,调试一段代码,你是不是还得切换快捷键,反应一会儿。

其实这个可以通过行政手段来做到,你可以规定项目中不能使用Lombok,也可以规定大家都使用Lombok。就好比现在,我推荐团队使用阿里Java开发手册对应的插件一样,就为了规范代码,让大家写出的代码保持一致性。

代码耦合度增加

文章中提到一个模块使用了Lombok,其他依赖模板也必须使用,耦合性加大。解释利用同上,如果使用maven构建的话可以给lombok的依赖加上true,这样lombok的依赖不会传递给引用的项目,而此模块的jar已经生成了getter/setter方法,并不影响使用。

个人爱好的不喜欢

最后,文章提到“使用Lombok,一时觉得很爽,但它却污染了你的代码,破坏了Java代码的完整性,可读性和安全性,同时还增加的团队的技术债务,这是一种弊大于利,得不偿失的操作。”

这个可能是纯属个人喜好吧。对于完整性、可读性和安全性的影响上面也逐一说明了,更是称不上“得不偿失”。

总结一下

通过上面的分析,其实作者很多观点是立不住脚的,而且也浮于表面。

就个人而言,唯一赞同可能就是“强迫使用”,但并不是无解的。如果大家都不爱用,那就都不用,如果只有一个人用,可以通过行政性手段约束,但不能成为摒弃一项工具的理由。

这就好比,一个项目中大家都在用mybatis,突然有一个人用起了Hibernate,这比单单使用Lombok更加不可理喻吧。

再次声明,用不用纯粹喜好,不影响根本问题,不喜欢就不用。就个人而言,希望使用,也推荐使用,学习成本本身也比较低,而且如果要用就用好,发挥它的便利之处,规避它的不足。

如果你决定使用,那就继续看看下面Lombok使用中真实的坑。

Lombok的坑

第一,由于Lombok使用比较简单,而且代码也变得简单,针对初学者容易只知其然,不知其所以然。注解用的很溜,但不明白或不清楚注解到底干了什么。

其实这是学习任何一项技术都会遇到的问题,建议在学习使用新技术、新框架时对自己要求严格那么一点点。

第二,@Data定义一个类的时候,会自动帮我们生成equals()方法。如果你对equals方法和hashcode方法有特殊的要求,建议自己手动实现。

如果实体类有继承关系,那么只使用@Data注解而不使用@EqualsAndHashCode(callSuper=true)的话,此时生成的equals方法只会比较子类的属性字段,不会考虑父类的继承属性。

笔者的一点小想法

其实本篇文章本没必要写的,直白说就是爱用不用,争论的意义也并不大。知道它的缺点,知道它的优点,取其精华去其糟粕即可。

但多次看到那篇文章被转载,真的容易误导一部分读者,还没有使用Lombok,还没有了解Lombok,就因为一篇说它“不好”的文章而将其拒之门外,这不是应该的学习态度。应该了解它,熟悉它,实践它,而不仅仅是给它贴一个标签。

对于每篇文章的观点,也应该辨证的去看,当然包括本篇文章中的观点和看法。



Lombok插件如此不好?但我选择继续使用…插图

关注公众号:程序新视界,一个让你软实力、硬技术同步提升的平台

除非注明,否则均为程序新视界原创文章,转载必须以链接形式标明本文链接

本文链接:http://choupangxia.com/2020/10/20/lombok-plugin/