Lombok шпаргалка. Плагин Ломбока для Intellij idea позволяет ide обрабатывать файлы, где есть аннотации Ломбока и предполагать, что в этих файлах после компиляции будет добавлен соответствующий код.

• Название: Плагин Ломбока для Intellij idea позволяет ide обрабатывать файлы, где есть аннотации Ломбока и предполагать, что в этих файлах после компиляции будет добавлен соответствующий код.
• Анкор: Lombok шпаргалка
• Дата: 16.06.2022
• Размер: 68.72 Kb.
• Имя файла: Lombok.rtf
• Тип: Документы; #597407

Lombok позволяет использовать аннотации для сокращения количества кода, код будет автоматически генерироваться во время компиляции.

Плагин Ломбока для IntelliJ IDEA позволяет IDE обрабатывать файлы, где есть аннотации Ломбока и предполагать, что в этих файлах после компиляции будет добавлен соответствующий код. Поэтому IDE может предлагать подсказки по методам, которых ещё нет в коде, и не подсвечивать красным использование таких методов.

Подключение через Maven в pom.xml:

<dependency>
<groupId>org.projectlombokgroupId>
<artifactId>lombokartifactId>
<version>1.18.22version>
<scope>providedscope>
dependency>

Файл lombok.config — файл общих настроек ломбока для всего проекта, лежит в корне проекта. Настройки, указанные здесь, будут применяться для всех соответствующих аннотаций ломбока во всём проекте. Лучше использовать этот файл, чем указывать эти настройки отдельно в каждом классе. Настройки:

• 
  lombok.accessors.chain = true
  
• 
  lombok.toString.callSuper = call
  
• 
  lombok.equalsAndHashCode.callSuper = call
  

Аннотации:

@Getter — генерирует геттеры для полей для полей класса

@Setter — генерирует сеттеры для полей для полей класса

@EqualsAndHashCode — генерирует методы equals() и hashCode(). Необязательные параметры:

• 
  exclude = String[] fields и аннотация @EqualsAndHashCode.Exclude для исключения определённых полей из метода. Такое может понадобиться, если, например, два класса представляют собой сущности БД и между ними есть связь, в этом случае в обоих классах будут ссылки друг на друга, из-за чего при использовании equals() или hashCode() у любого из этих классов будет выброшена ошибка StackOverflowError.
  
• 
  boolean callSuper, по умолчанию false. Если мы пишем аннотацию @EqualsAndHashCode для класса, который наследуется от другого класса, то нам будет выдано предупрежение о том, что мы реализуем методы equals/hashCode без вызова суперкласса, что означает, что при генерации этих методов ломбоком не учитываются поля из суперкласса. Чтобы это исправить, можно установить значение для callSuper = true, тогда сперва будут вызнываны методы equals и hashCode из суперкласса перед вычислением значений этих методов для полей из этого класса.
  

@ToString — генерирует метод toString(). Необязательные параметры:

• 
  exclude = String[] fields для исключения определённых полей из метода toString(). Для этой цели также можно прописать @ToString.Exclude у соответствующих полей.
  
• 
  boolean callSuper, по умолчанию false. Если установить true, то включит в выходные данные метода toString реализацию toString() из суперкласса.
  

@Data — заменяет аннотации @Getter, @Setter, @ToString, @EqualsAndHashCode и @RequiredArgsConstructor.

@AllArgsConstructor — генерирует конструктор со всеми параметрами. Важно: при использовании этой аннотации Java не создаст автоматически конструктор по умолчанию (без параметров), если он нужен, то в дополнение к этой аннотации надо прописать аннотацию @NoArgsConstructor

@NoArgsConstructor — генерирует конструктор по умолчанию (без параметров).

@RequiredArgsConstructor — генерирует конструктор для всех не инициализированных final и @NonNull параметров.

@Builder — позволяет автоматически создавать код, необходимый для создания экземпляра вашего класса. Его преимущество в том, что с ним можно создавать объекты с указанием только тех полей, которые нам необходимы. Без этой аннотации пришлось бы делать отдельные конструкторы для каждого необходимого способа создания пользователя. Под капотом билдер создаёт вложенный класс, дублирующий поля исходного класса, что затрачивает больше памяти, однако это приносится в жертву в угоду красоте и лаконичности кода. Если же разрабатывается приложение highload, то билдер могут не использовать. В следующем примере видно, что мы создаём пользователя без указания его id:

@Builder
public class User {
private int id;
private String firstName;
private String lastName;
private int age;
}

User user = User.builder()
.firstName("Марк")
.lastName("Энгельсон")
.age(28)
.build();

@Accessors(fluent = true, chain = true) — изменяет способ генерации геттеров и сеттеров с помощью Lombok. fluent позволяет убрать слова get и set из названий соответствующих методов, например: вместо getName() будет просто name(), a вместо setName(String name) будет name(String name). По умолчанию fluent = false. chain изменяет сеттер так, что он начинает возвращать this, это означает, что мы можем использовать последовательный вызов сразу нескольких сеттеров, например: new User().setName("Иван").setAge("25");

@Slf4j — указывается над классом, который должен логироваться, после чего не меняя наш код, можно подкладывать другую зависимость, настройку другого логгера, и всё будет работать через другой логгер.