Lombok getter / setter проти запису Java 14

Я люблю проект « Ломбок», але в ці дні я читаю і пробую деякі нові функції java 14.

Всередині нової можливості є ключове слово запису, яке дозволяє створити клас із вже вбудованою функцією: конструктор, приватні кінцеві поля, accessors, equals / hashCode, getters, toString методи.

Тепер моє запитання: краще покластися на особливості Lombok чи варто почати використовувати функцію запису:

Краще скористатися цим:

record Person (String name, String surname) {}

або що:

@AllArgsConstructor
@ToString
@EqualsAndHashCode
public class GetterSetterExample {
  @Getter private int name;
  @Getter private int surname;
}

Які плюси і мінуси обох підходів?

Lombok та recordособливості мови Java - це різні інструменти для різних речей. Існує деяке поверхневе перекриття, але не дозволяйте це відволікати вас.

Ломбок багато в чому стосується синтаксичної зручності; це макропроцесор, попередньо завантажений деякими відомими корисними моделями коду. Це не дає жодної семантики; він просто автоматизує шаблони, згідно з деякими кнопками, встановленими в коді, з анотаціями. Lombok суто стосується зручності впровадження класів передачі даних.

Записи - це смислова особливість; вони номінальні кортежі . Роблячи семантичне оголошення, яке Point є кордоном (int x, int y), компілятор може отримати його опис, а також побудову протоколів побудови, декларування, рівності, хешування та рядкового представлення з цього опису стану. Оскільки вони несуть семантику, читачі та рамки також можуть з більшою впевненістю ставитись до API записів. (Це також може бути синтаксично зручним; якщо так, то це чудово.)

Я вже деякий час граю з цією комбінацією, і з невеликим рукою я можу перерахувати наступні відмінності:

Ломбок

• Записи ще не є випущеною функцією і є лише функцією попереднього перегляду. Тож залишатися з Ломбоком має більше сенсу.
• Вони ще не настільки потужний інструмент для усунення Ломбока всіх разом. Зауважте, що бібліотека може запропонувати набагато більше, ніж просто @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
• Досвідчений власним бажанням, EqualsAndHashCodeце не те саме, що можна було б очікувати, коли справа стосується міграції до записів .

Записи

• З іншого боку, якщо вимога вашого об’єктного представлення має бути "носієм даних", ви все одно можете шукати переваги Records, не покладаючись на додаткову бібліотеку, щоб зменшити код котлопластів, щоб точно це виконати. Саме тому, як остаточна примітка, цей блог читає наступне:

  Це також допоможе командам усунути багато ручно кодованих реалізацій базового шаблону та зменшити або усунути потребу в таких бібліотеках, як Lombok.

Звичайно, щодня щоденно завжди розумно, виходячи з вимог проекту, обирати, який шлях слід слідувати та практикувати.

NB: Замість цієї ялинки анотацій ви можете просто використовувати @Valueна уроці. Зауважте, що це робить клас остаточним і робить усі поля як приватними, так і заключними, а також дає всі інші. Це близько до записів (вони теж є остаточними, і всі поля всередині є остаточними).

recordвсе ще в попередньому перегляді, тому для виробничого коду він, очевидно, ще не підходить. Використовуйте ломбок.

Після того, як записи не переглядаються, це складніше. Ломбок - ДОПОМОГА гнучкішим; ви можете легко поміняти місцями на якийсь новий аспект без необхідності переписати весь код (ви можете просто, наприклад, додати в клас свій пункт "extends", не використовуючи для цього рукописного методу рівних та хеш-кодів; те, що записи не можуть дати вам). Lombok також надає більше можливостей: Ви можете, наприклад, додати будівельника, додавши @Builderпримітку; не щось може зробити записи.

Якщо це малоймовірно, ви будете використовувати будь-що з цього для класу, який ви проектуєте - я б використовував записи.

ВІДПОВІДАЛЬНІСТЬ: Я є головним учасником проекту "Ломбок".