Lombok注解之@Accessors使用

在实体类上使用该注解,例如:@Data@EqualsAndHashCode(callSuper = false)@Accessors(fluent = true)@AllArgsConstructor@NoArgsConstructorpublic class Coldknow extends Model<Coldknow> {    private static final long serialVersionUID = 1L;    @TableId(value = "id", type = IdType.AUTO)    private Integer id;    private String title;    private String img;    private String text;    @Override    protected Serializable pkVal() {        return this.id;    }}@Accessors(fluent = true)使用后可以让你在get/set时候省去get/set例如:        Coldknow coldknow = new Coldknow();//        set设置属性        coldknow.title("标题");        coldknow.img("http://cway.top/1.png");//        get属性        System.out.println(coldknow.title());@Accessors(chain = true)使用后支持链式set,即:Coldknow coldknow = new Coldknow().setTitle("标题").setImg("http://cway.top/1.png")        .setText("内容");System.out.println(coldknow);@Accessors(prefix="t")生成getter/setter时忽略指定字符前缀,但前缀后必须是小驼峰命名,例如 fName,生成的get/set方法则变成getName()而非getFName(),具体观察下图:

Lombok注解之@Accessors使用

Lombok相关注解及其使用

主要用注解方式来简化Java实体类的书写,使代码更简洁清晰,所需依赖,例如:<dependency>    <groupId>org.projectlombok</groupId>    <artifactId>lombok</artifactId>    <version>1.16.20</version>    <scope>provided</scope></dependency>@Data注解在类上,会为类的所有属性自动生成setter/getter、equals、canEqual、hashCode、toString方法@ToString、@EqualsAndHashCode、@Getter/@Setter、@RequiredArgsConstructor的所有特性(),如为final属性,则不会为该属性生成setter方法。@Getter/@Setter注解,此注解在属性上,可以为相应的属性自动生成Getter/Setter方法@NonNull该注解用在属性或构造器上,Lombok会生成一个非空的声明,可用于校验参数,能帮助避免空指针。@Cleanup该注解能帮助我们自动调用close()方法,很大的简化了代码,例如:import lombok.Cleanup;import java.io.*;public class CleanupExample {  public static void main(String[] args) throws IOException {    @Cleanup InputStream in = new FileInputStream(args[0]);    @Cleanup OutputStream out = new FileOutputStream(args[1]);    byte[] b = new byte[10000];    while (true) {      int r = in.read(b);      if (r == -1) break;      out.write(b, 0, r);    }  }}@EqualsAndHashCode默认情况下,会使用所有非静态(non-static)和非瞬态(non-transient)属性来生成equals和hasCode,也能通过exclude注解来排除一些属性。示例:import lombok.EqualsAndHashCode;@EqualsAndHashCode(exclude={"id", "shape"})public class EqualsAndHashCodeExample {  private transient int transientVar = 10;  private String name;  private double score;  private Shape shape = new Square(5, 10);  private String[] tags;  private int id;    public String getName() {    return this.name;  }    @EqualsAndHashCode(callSuper=true)  public static class Square extends Shape {    private final int width, height;        public Square(int width, int height) {      this.width = width;      this.height = height;    }  }}@ToString注解,Lombok会生成一个toString()方法,默认情况下,会输出类名、所有属性(会按照属性定义顺序),用逗号来分割。通过将includeFieldNames参数设为true,就能明确的输出toString()属性。这一点是不是有点绕口,通过代码来看会更清晰些。示例:import lombok.ToString;@ToString(exclude="id")public class ToStringExample {  private static final int STATIC_VAR = 10;  private String name;  private Shape shape = new Square(5, 10);  private String[] tags;  private int id;    public String getName() {    return this.getName();  }    @ToString(callSuper=true, includeFieldNames=true)  public static class Square extends Shape {    private final int width, height;        public Square(int width, int height) {      this.width = width;      this.height = height;    }  }}@NoArgsConstructor, @RequiredArgsConstructor and @AllArgsConstructor无参构造器、部分参数构造器、全参构造器。Lombok没法实现多种参数构造器的重载。 Lombok的优缺点优点:能通过注解的形式自动生成构造器、getter/setter、equals、hashcode、toString等方法,提高了一定的开发效率让代码变得简洁,不用过多的去关注相应的方法属性做修改时,也简化了维护为这些属性所生成的getter/setter方法等缺点:不支持多种参数构造器的重载虽然省去了手动创建getter/setter方法的麻烦,但大大降低了源代码的可读性和完整性,降低了阅读源代码的舒适度总结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://projectlombok.org/features/https://github.com/rzwitserloot/lombok?spm=a2c4e.11153940.blogcont59972.5.2aeb6d32hayLHvhttps://www.zhihu.com/question/42348457https://blog.csdn.net/ghsau/article/details/52334762转载:https://www.cnblogs.com/heyonggang/p/8638374.html