Lombok入门使用教程及其优缺点详解(下）

三、为什么不推荐使用Lombok？

Lombok的优点显而易见，可以帮助我们省去很多冗余代码，实际上，从我个人角度来看，Java开发项目中，并不推荐使用Lombok，但潘老师还是介绍了它的使用方法，因为在一些公司存在这样的使用场景，下面我们来看一下潘老师为什么不推荐使用Lombok，它都有哪些缺点？

1） 高侵入性，强迫队友

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

2）代码可调试性降低

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

3） 影响版本升级

Lombok对于代码有很强的侵入性，就可能带来一个比较大的问题，那就是会影响我们对JDK的升级。按照如今JDK的升级频率，每半年都会推出一个新的版本，但是Lombok作为一个第三方工具，并且是由开源团队维护的，那么他的迭代速度是无法保证的。所以，如果我们需要升级到某个新版本的JDK的时候，若其中的特性在Lombok中不支持的话就会受到影响。还有一个可能带来的问题，就是Lombok自身的升级也会受到限制。因为一个应用可能依赖了多个jar包，而每个jar包可能又要依赖不同版本的Lombok，这就导致在应用中需要做版本仲裁，而我们知道，jar包版本仲裁是没那么容易的，而且发生问题的概率也很高。

4）注解使用有风险

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

5）可能会破坏封装性

使用过程中如果不小心，在一定程度上就会破坏代码的封装性。举个简单的例子，我们定义一个购物车类，并且使用了@Data注解：

@DatapublicclassShoppingCart { 
//商品数目privateintitemsCount; 
//总价格privatedoubletotalPrice; 
//商品明细privateListitems=newArrayList<>();
}

我们知道，购物车中商品数目、商品明细以及总价格三者之前其实是有关联关系的，如果需要修改的话是要一起修改的。但是，我们使用了Lombok的@Data注解，对于itemsCount 和 totalPrice这两个属性，虽然我们将它们定义成 private 类型，但是提供了 public 的 getter、setter 方法。

外部可以通过 setter 方法随意地修改这两个属性的值，我们可以随意调用 setter 方法，来重新设置 itemsCount、totalPrice 属性的值，这也会导致其跟 items 属性的值不一致。

而面向对象封装的定义是：通过访问权限控制，隐藏内部数据，外部仅能通过类提供的有限的接口访问、修改内部数据。所以，暴露不应该暴露的 setter 方法，明显违反了面向对象的封装特性。

好的做法应该是不提供getter/setter，而是只提供一个public的addItem方法，同时取修改itemsCount、totalPrice以及items三个属性。

因此，在此种情况下，就不适合使用Lombok，或者只用@Getter不用@Setter，而别直接使用@Data，在使用过程中，需要多多小心。

四、总结

Lombok虽好，但缺点也不少，如果你在公司团队开发中被强X了，你就只能使用，如果新项目开发，能不用就尽量别用了，否则坑也不少的！