lombok优缺点

优势：

1. 能经过注解的形式自动生成构造器、getter/setter、equals、hashcode、toString等方法，提升了必定的开发效率
2. 让代码变得简洁，不用过多的去关注相应的方法
3. 属性作修改时，也简化了维护为这些属性所生成的getter/setter方法等

缺点：

1. 不支持多种参数构造器的重载
2. 虽然省去了手动建立getter/setter方法的麻烦，但大大下降了源代码的可读性和完整性，下降了阅读源代码的温馨度

 

 

Lombok总结： 

Lombok虽然有不少优势，但Lombok更相似于一种IDE插件，项目也须要依赖相应的jar包。Lombok依赖jar包是由于编译时要用它的注解，为何说它又相似插件？由于在使用时，eclipse或IntelliJ IDEA都须要安装相应的插件，在编译器编译时经过操做AST（抽象语法树）改变字节码生成，变向的就是说它在改变java语法。它不像spring的依赖注入或者mybatis的ORM同样是运行时的特性，而是编译时的特性。这里我我的最感受不爽的地方就是对插件的依赖！由于Lombok只是省去了一些人工生成代码的麻烦，但IDE都有快捷键来协助生成getter/setter等方法，也很是方便。

知乎上有位大神发表过对Lombok的一些见解：

这是一种低级趣味的插件，不建议使用。JAVA发展到今天，各类插件层出不穷，如何甄别各类插件的优劣？能从架构上优化你的设计的，能提升应用程序性能的 ，
实现高度封装可扩展的...， 像lombok这种，像这种插件，已经不单单是插件了，改变了你如何编写源码，事实上，少去了代码你写上去又如何？ 
若是JAVA家族处处充斥这样的东西，那只不过是一坨披着金属颜色的屎，早晚会被其它的语言取代。

虽然话糙但理确实不糙，试想一个项目有很是多相似Lombok这样的插件，我的以为真的会极大的下降阅读源代码的温馨度。

虽然很是不建议在属性的getter/setter写一些业务代码，但在多年项目的实战中，有时经过给getter/setter加一点点业务代码，能极大的简化某些业务场景的代码。所谓取舍，也许就是这时的舍弃必定的规范，取得极大的方便。

我如今很是坚信一条理念，任何编程语言或插件，都仅仅只是工具而已，即便工具再强大也在于用的人，就如同小米加步枪照样能赢飞机大炮的道理同样。结合具体业务场景和项目实际状况，无需一味追求高大上的技术，适合的才是王道。

Lombok有它的得天独厚的优势，也有它避之不及的缺点，熟知其优缺点，在实战中灵活运用才是王道。

 

 

 

原文：https://www.cnblogs.com/heyonggang/p/8638374.html

 

声明：此博客为我的学习之用，如与其余做品雷同，纯属巧合，转载请指明出处！