Lombok @builder on a class that extends another class

走远了吗. 提交于 2019-12-03 01:11:31

See in https://blog.codecentric.de/en/2016/05/reducing-boilerplate-code-project-lombok/ (@Builder and inheritance part)

Adjusted to your classes

@AllArgsConstructor
public class Parent {
  private double d;
  private float e;
}

public class Child extends Parent {
  private String a;
  private int b;
  private boolean c;

  @Builder
  public Child(String a, int b, boolean c, double d, float e) {
    super(d, e);
    this.a = a;
    this.b = b;
    this.c = c;
  }
}

With this setup

Child child = Child.builder().a("aVal").b(1000).c(true).d(10.1).e(20.0F).build();

works correctly

Since release 1.18.2 lombok includes the new experimental @SuperBuilder. It supports fields from superclasses (also abstract ones). With it, the solution is as simple as this:

@SuperBuilder
public class Child extends Parent {
   private String a;
   private int b;
   private boolean c;
}

@SuperBuilder
public class Parent {
    private double d;
    private float e;
}

Child instance = Child.builder().b(7).e(6.3).build();

Update 2019-10-09: If you use IntelliJ, you need at least version 0.27 of the IntelliJ Lombok plugin to use @SuperBuilder.

PS: @AllArgsConstructor(onConstructor=@__(@Builder)) does not work because @Builder is an annotation-processing annotation that lombok translates to code during compilation. Generating and then translating new lombok annotation would require several iterations of annotation processing, and lombok does not support that. @Autowired, in contrast, is a regular Java annotation available at runtime.

I have a similar but slightly different use case. In my case, I have a chain of abstract super classes that build and execute requests. Different requests share some common parameters, but not every request supports all parameters. The builders for concrete requests should only provide methods for setting supported parameters for a given request.

I started out with the constructor-based builder implementations, but this resulted in too much boilerplate code, especially if you have many fields to be configured. I have now come up with the following solutions, which looks much cleaner to me.

Basically the concrete subclasses define the actual fields that the Builder should support, and the Getter annotation results in the corresponding superclass methods to be overridden. The getters in the abstract superclasses can even be defined as abstract to require concrete implementations to define those fields.

public abstract class AbstractSuperClass1 {
    protected String getParamA() { return "defaultValueA"; }

    public final void doSomething() {
        System.out.println(getParamA());
        doSomeThingElse();
    }

    protected abstract void doSomeThingElse();
}

public abstract class AbstractSuperClass2 extends AbstractSuperClass1 {
    protected String getParamB() { return "defaultValueB"; }

    protected void doSomeThingElse() {
        System.out.println(getParamB());
    }
}

import lombok.AccessLevel;
import lombok.Builder;
import lombok.Getter;

@Getter(AccessLevel.PROTECTED) @Builder
public class ConcreteClass1 extends AbstractSuperClass2 {
    private final String paramA;
    // Not supported by this implementation: private final String paramB;

    public static void main(String[] args) {
        ConcreteClass1.builder()
           .paramA("NonDefaultValueA")
           .build().doSomething();
    }
}

import lombok.AccessLevel;
import lombok.Builder;
import lombok.Getter;

@Getter(AccessLevel.PROTECTED) @Builder
public class ConcreteClass2 extends AbstractSuperClass2 {
    private final String paramA;
    private final String paramB;

    public static void main(String[] args) {
        ConcreteClass2.builder()
            .paramA("NonDefaultValueA").paramB("NonDefaultValueB")
            .build().doSomething();
    }
}
易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!