Lombok java builder method

Lombok @Builder

Аннотация @Builder была представлена как новая возможность в Lombok v0.12.0.

Аннотация @Builder получила поддержку @Singular и была переведена в основной пакет Lombok в Lombok v1.16.0.

Аннотация @Builder создаёт составной builder API для ваших классов.

@Builder даёт вам возможность автоматически генерировать код, необходимый для создания экземпляров ваших классов кодом вида:

Person . builder ( ) . name ( «Adam Savage» ) . city ( «San Francisco» ) . job ( «Mythbusters» ) . job ( «Unchained Reaction» ) . build ( ) ;

@Builder может быть указан для класса или конструктора или статического метода. Чаще всего он указывается для класса или для конструктора, но легче его объяснить на примере статического метода.

Статический метод с аннотацией @Builder (дальше я буду называть его целью) приводит к генерации семи вещей:

• Статический вложенный класс с именем FooBuilder и с теми же аргументами, что и статический метод (называемый builder).
• В builder: Одно приватное нестатическое поле для каждого параметра в цели.
• В builder: Пустой конструктор без аргументов с модификатором доступа package private.
• В builder: Метод для установки значения для каждого параметра. Он имеет тот же тип аргумента, что и параметр и то же имя. Он возвращает builder, так что методы установки значения могут быть выстроены в цепочку, как в примере выше.
• В builder: Метод build(), вызывающий статический метод, передающий туда все поля. Он возвращает тот же тип, что и цель.
• В builder: Подходящая реализация toString().
• В классе, содержащем цель: Статический метод builder(), который создаёт экземпляр builder-а.

Любой из перечисленных элементов для генерации просто пропускается, если элемент уже существует (не зависимо от количество параметров, смотрится только имя). Это касается и самого builder — если класс уже существует, то Lombok просто вставляет поля и методы в уже существующий класс, если этих полей/методов ещё нет, конечно. Поэтому вы не можете добавлять любую другую аннотацию Lombok, генерирующую метод или конструктор к builder-у. Например, вы не можете добавить @EqualsAndHashCode к классу builder-а.

@Builder может генерировать так называемые singular-методы. Они берут один параметр вместо целого списка и добавляют элемент к списку. Например: Person . builder ( ) . job ( «Mythbusters» ) . job ( «Unchained Reaction» ) . build ( ) ; приведёт к тому, что List jobs поле будет иметь две строки. Для этого к полю/параметру должна быть добавлена аннотация @Singular.

Теперь когда со статическим методом всё понятно, указание аннотации @Builder для конструктора работает так же. Фактически конструкторы — это просто статические методы, имеющие особый синтаксис для их вызова. Их возвращаемый тип — это класс, который они создают, а их параметры те же, что и параметры класса.

В конечном итоге применение @Builder к классу — это то же самое, что и добавление @AllArgsConstructor(access = AccessLevel.PACKAGE) к классу и применение аннотации @Builder к этому all-args-конструктору. Это работает, только если вы не писали явных конструкторов. Если уже есть явный конструктор, то добавляйте аннотацию @Builder к этому конструктору, а не к классу.

Если вы используете @Builder для генерации builder-ов, создающих экземпляры вашего класса (это обычно так и есть, если вы не используете @Builder для статического метода, который не возвращает ваш тип), вы можете использовать @Builder ( toBuilder = true ) для генерации метода экземпляров вашего класса toBuilder(). Он создаёт новый builder, который уже содержит все значения из текущего экземпляра. Вы можете добавить @Builder.ObtainVia к параметрам (в случае использования конструктора или статического метода) или полям (в случае @Builder для типа), для указания альтернативного способа, которым значения этих полей/параметров получаются из экземпляра. Например, вы можете указать выполнение метода: @Builder . ObtainVia ( method = «calculateFoo» ) .

Имя класса builder-а — FoobarBuilder, где Foobar — это упрощённая, начинающаяся с заглавной буквы форма цели, то есть это имя вашего класса при использовании @Builder для конструкторов или типов, и это имя возвращаемого типа при использовании для статических методов.Например, если аннотация @Builder применена для класса с именем com.yoyodyne.FancyList, то имя builder-а будет FancyListBuilder. Если @Builder применён к статическому методу, возвращающему void, то класс будет с именем VoidBuilder.

Настраиваемые части builder-а:

• Имя класса builder-а (по умолчанию: return type + ‘Builder’ )
• Имя метода build() (по умолчанию: «build» )
• Имя метода builder() (по умолчанию: «builder» )
• Нужен ли toBuilder() (по умолчанию: нет)

Пример использования, где все настройки отличны от значений по умолчанию:

Источник

Annotation Type Builder

The builder annotation creates a so-called ‘builder’ aspect to the class that is annotated or the class that contains a member which is annotated with @Builder .

If a member is annotated, it must be either a constructor or a method. If a class is annotated, then a package-private constructor is generated with all fields as arguments (as if @AllArgsConstructor(access = AccessLevel.PACKAGE) is present on the class), and it is as if this constructor has been annotated with @Builder instead. Note that this constructor is only generated if you haven’t written any constructors and also haven’t added any explicit @XArgsConstructor annotations. In those cases, lombok will assume an all-args constructor is present and generate code that uses it; this means you’d get a compiler error if this constructor is not present.

The effect of @Builder is that an inner class is generated named TBuilder , with a private constructor. Instances of TBuilder are made with the method named builder() which is also generated for you in the class itself (not in the builder class).

The TBuilder class contains 1 method for each parameter of the annotated constructor / method (each field, when annotating a class), which returns the builder itself. The builder also has a build() method which returns a completed instance of the original type, created by passing all parameters as set via the various other methods in the builder to the constructor or method that was annotated with @Builder . The return type of this method will be the same as the relevant class, unless a method has been annotated, in which case it’ll be equal to the return type of that method.

class Example  < private T foo; private final String bar; private Example(T foo, String bar) < this.foo = foo; this.bar = bar; >public static ExampleBuilder builder() < return new ExampleBuilder(); > public static class ExampleBuilder  < private T foo; private String bar; private ExampleBuilder() <>public ExampleBuilder foo(T foo) < this.foo = foo; return this; >public ExampleBuilder bar(String bar) < this.bar = bar; return this; >@java.lang.Override public String toString() < return "ExampleBuilder(foo = " + foo + ", bar = " + bar + ")"; >public Example build() < return new Example(foo, bar); >> >

Источник

Lombok @Builder

Lombok’s @Builder annotation is a useful technique to implement the builder pattern that aims to reduce the boilerplate code. In this tutorial, we will learn to apply @Builder to a class and other useful features.

Ensure you have included Lombok in the project and installed Lombok support in the IDE.

If we want to marshal or unmarshal the builder classes with Jackson then we should be using the @Jacksonized annotation.

The @Builder annotation produces complex builder APIs for the annotated POJO classes.

For example, if we annotate a class Article annotated with @Builder annotation, we can create Article instances using builder API. Internally a class ArticleBuilder and a build() method are auto-generated along with setter like methods for each parameter to the builder class.

import java.util.List; import lombok.Builder; import lombok.Getter; import lombok.ToString; @Builder @Getter @ToString public class Article < private Long id; private String title; private Listtags; >

Article a = Article.builder() .id(1L) .title("Test Article") .tags(Collections.singletonList("Demo")) .build();

The @Getter annotation adds accessor methods and @ToString annotation overrides the toString() method printing the values of relevant fields.

2. @Singular Method Support

Using @Singular with @Builder generated singular methods for collection parameters/fields in the auto-generated class. This singular method enables adding a single item to the collection. Note that @Singular annotation supports the Guava collection classes as well.

For example, when we add @Singular to tags field:

@Builder @Getter @ToString public class Article < private Long id; private String title; @Singular private Listtags; >

We can achieve the below behavior in the Article class builder.

Article a = Article.builder() .id(1L) .title("Test Article") .tag("TestTag1") .tag("TestTag2") .build(); 

3. @Builder.Default for Default Values

Sometimes, we want to assign a default value to a field if the client does not populate that field while creating the instance. In such cases, we can use the @Builder.Default on those fields.

@Builder @Getter @ToString public class Article < private Long id; @Builder.Default private String title = "Title Placeholder"; @Singular private Listtags; >

In the above example, if we do not assign the value of title in a new instance, it will be set to “Title Placeholder.”

Article a = Article.builder() .id(1L) .tag("TestTag1") .tag("TestTag2") .build(); // Article(id=1, title=Title Placeholder, tags=[TestTag1, TestTag2]) System.out.println(a); 

4. Creating Prototype Instances

A prototype instance is a copy of an existing object rather than creating a new instance from scratch. We can achieve this by enabling the functionality with @Builder(toBuilder = true) and using the toBuilder() method on any existing instance.

@Builder(toBuilder = true) @Getter @ToString public class Article < private Long id; @Builder.Default private String title = "Title Placeholder"; @Singular private Listtags; >

Notice the article title has been changed in the second instance but other fields are the same as the first instance

Article a = Article.builder() .id(1L) .title("Test Article") .tag("Demo") .build(); //Article(id=1, title=Test Article, tags=[Demo]) System.out.println(a); Article.ArticleBuilder nearCopyBuilder = a.toBuilder(); Article b = nearCopyBuilder.title("Final Title").build(); //Article(id=1, title=Final Title, tags=[Demo]) System.out.println(b);

5. Required Parameters to Instance

Our Article class instance does not make sense if it does not have an article id . It should be a mandatory field. For making fields mandatory, we need to add our own ArticleBuilder class with required fields as constructor parameters.

Also, do not forget to add @NonNull annotation if we want to make sure that the client is not passing a null to satisfy the required input validation.

@Builder @Getter @ToString public class Article < @NonNull private final Long id; private String title = "Title Placeholder"; @Singular private final Listtags; public static ArticleBuilder builder(final Long id) < return new ArticleBuilder().id(id); >>

Article a = Article.builder(1L) .title("Test Article") .tag("Data") .build(); //Article(id=1, title=Test Article, tags=[Data]) System.out.println(a);

Lombok @Builder annotation is an excellent way of introducing the builder pattern into POJO classes. It supports all kinds of operations and configurations, including marshaling and unmarshalling.

Refer to the official documentation to know the latest features added and any issues.

Источник