谈谈Lombok的坑

Lombok 是一个 Java 库，通过注解的方式在编译时自动为类生成 getter、setter、equals、hashCode 等方法，以简化代码和提高开发效率。本文主要谈谈代码简化背后的代价。

引入Lombok之前是怎么做的

IDE中添加getter/setter, toString等代码：
在这里插入图片描述

@Data

在使用Lombok过程中，如果对于各种注解的底层原理不理解的话，很容易产生意想不到的结果。举一个简单的例子，我们知道，当我们使用@Data定义一个类的时候，会自动帮我们生成equals()方法。但是如果只使用了@Data，而不使用@EqualsAndHashCode(callSuper=true)的话，会默认是@EqualsAndHashCode(callSuper=false),这时候生成的equals()方法只会比较子类的属性，不会考虑从父类继承的属性，无论父类属性访问权限是否开放。这就可能得到意想不到的结果。

代码可读性

在代码中使用了Lombok，确实可以帮忙减少很多代码，因为Lombok会帮忙自动生成很多代码。但是这些代码是要在编译阶段才会生成的，所以在开发的过程中，其实很多代码其实是缺失的。在代码中大量使用Lombok，就导致代码的可读性会低很多，而且也会给代码调试带来一定的问题。比如，我们想要知道某个类中的某个属性的getter方法都被哪些类引用的话，就没那么简单了。

侵入性

因为Lombok的使用要求开发者一定要在IDE中安装对应的插件。如果未安装插件的话，使用IDE打开一个基于Lombok的项目的话会提示找不到方法等错误。导致项目编译失败。也就是说，如果项目组中有一个人使用了Lombok，那么其他人就必须也要安装IDE插件。否则就没办法协同开发。更重要的是，如果我们定义的一个jar包中使用了Lombok，那么就要求所有依赖这个jar包的所有应用都必须安装插件，这种侵入性是很高的。

破坏了封装性

假设我们有一个User类，使用Lombok的@Data注解来自动生成getter和setter方法：

import lombok.Data;@Data
public class User {private String name;private int age;
}

在这种情况下，虽然我们没有显式地编写getter和setter方法，但Lombok会在编译时自动生成它们。这样，外部代码可以直接访问和修改User类的name和age属性，从而破坏了封装性。
而面向对象封装的定义是：通过访问权限控制，隐藏内部数据，外部仅能通过类提供的有限的接口访问、修改内部数据。所以，暴露不应该暴露的 setter 方法，明显违反了面向对象的封装特性。
好的做法应该是不提供getter/setter，而是只提供一个public的add方法，同时去修改name、age属性。