Getter / setter Lombok vs rekord Java 14

10

Uwielbiam projekt Lombok, ale obecnie czytam i wypróbowuję niektóre nowe funkcje Java 14.

Wewnątrz nowej możliwości znajduje się słowo kluczowe record, które pozwala utworzyć klasę z już wbudowaną następującą funkcjonalnością: konstruktor, prywatne pola końcowe, akcesory, equals / hashCode, getters, metody toString.

Teraz moje pytanie brzmi: lepiej polegać na funkcji Lombok, czy też powinniśmy zacząć korzystać z funkcji nagrywania:

Lepiej użyć tego:

record Person (String name, String surname) {}

albo to:

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

Jakie są zalety i wady obu podejść?

— gixlg
źródło

Po pierwsze, recordnie będzie działać na rzeczy oczekujące programów pobierających i ustawiających w stylu JavaBeans.

— Mark Rotteveel

2

Komentarz Rotteveel oznacza, że metoda modułu dostępu do rekordu nosi tę samą nazwę właściwości. Więc alice.phoneNumber()zamiast konwencji JavaBeans o prefiksie get, jak w alice.getPhoneNumber().

— Basil Bourque

1

Ta recordfunkcja jest funkcją podglądu , ale nie jest jeszcze gotowa do użycia w produkcji.

— Basil Bourque

Rekordy mają wiele ograniczeń w porównaniu do klas, rekord nie może na przykład rozszerzyć innego rekordu lub klasy, sprawdź sekcję ograniczeń w tym JEP openjdk.java.net/jeps/359 w celu uzyskania dalszych szczegółów

— NAIT

9

Lombok i recordfunkcja języka Java to różne narzędzia do różnych rzeczy. Jest to powierzchowne nakładanie się, ale nie pozwól, aby cię to rozproszyło.

Lombok dotyczy głównie wygody syntaktycznej ; jest to makroprocesor wstępnie załadowany kilkoma znanymi użytecznymi wzorcami kodu. Nie nadaje żadnej semantyki; po prostu automatyzuje wzorce, zgodnie z niektórymi pokrętłami ustawionymi w kodzie za pomocą adnotacji. Lombok polega wyłącznie na wygodzie wdrażania klas przenoszących dane.

Zapisy są cechą semantyczną ; są krotkami nominalnymi . Dokonując deklaracji semantycznej, która Point jest krotką (int x, int y), kompilator może czerpać swoją reprezentację, a także protokoły konstrukcji, deklaracji, równości, mieszania i ciągów znaków z tego opisu stanu. Ponieważ zawierają one semantykę, czytniki i struktury mogą również z większym zaufaniem rozumieć interfejs API rekordów. (Może to być również wygodne pod względem składni; jeśli tak, to świetnie.)

— Brian Goetz
źródło

1

+1 Brian Goetz: Zakładając, że możesz pobrać aktualną wersję Lombok do swojego IDE. Zastanawiam się, czy Lombok ma jakąkolwiek znaczącą przewagę pod względem szybszego odczytu kodu, której nie dałby komentarz klasy.

— Bagażnik

4

Grałem z tą kombinacją również od jakiegoś czasu i przy odrobinie praktyczności mogłem wymienić następujące różnice:

Lombok

Rekordy nie są jeszcze funkcją wydaną, a jedynie funkcją podglądu. Dlatego pobyt w Lombok ma większy sens.
Nie są jeszcze tak potężnym narzędziem do całkowitego wyeliminowania Lomboka. Pamiętaj, że biblioteka ma znacznie więcej do zaoferowania niż tylko @Getter, @AllArgsConstructor, @ToString, @EqualsAndHashCode.
Doświadczony przez siebie, EqualsAndHashCodenie jest taki sam, jak można się spodziewać, jeśli chodzi o migrację do rekordów .

Dokumentacja

Z drugiej strony, jeśli wymóg reprezentacji obiektu ma być „nośnikiem danych”, możesz nadal szukać korzyści z rekordów, nie polegając na dodatkowej bibliotece, aby zredukować kod płyty wzorcowej, aby to dokładnie wykonać. Z tego powodu jako ostateczna notatka blog ten brzmi następująco:

Pomoże to również zespołom wyeliminować wiele ręcznie kodowanych implementacji podstawowego wzorca i zmniejszyć lub wyeliminować potrzebę bibliotek takich jak Lombok.

Oczywiście na co dzień, w oparciu o wymagania projektu zawsze mądrze jest wybrać sposób postępowania i postępowania.

— Naman
źródło

Uwaga - starałbym się na bieżąco aktualizować, dodając więcej przykładów na to, że użytkownik często korzysta z nich obu.

— Naman

3

Uwaga: Zamiast choinki z adnotacjami możesz po prostu użyć @Valuew klasie. Pamiętaj, że dzięki temu klasa jest ostateczna, a wszystkie pola są prywatne i końcowe, a także cała reszta. Jest to bliskie temu, czym są rekordy (one także są ostateczne, a wszystkie pola w nich są ostateczne).

recordjest wciąż w wersji zapoznawczej, więc w przypadku kodu produkcyjnego nie jest jeszcze odpowiednie. Użyj lomboka.

Gdy rekordy są poza podglądem, jest to bardziej skomplikowane. Lombok FAR bardziej elastyczne; możesz łatwo podmienić nowy aspekt bez konieczności przepisywania całego kodu (możesz na przykład dodać klauzulę „extends” do swojej klasy bez konieczności ręcznego pisania metody equals i hashCode; coś nie da ci rekordy). Lombok oferuje również więcej funkcji: Możesz na przykład dodać konstruktora, dodając @Builderadnotację; nic nie może zrobić.

Jeśli jest bardzo mało prawdopodobne, że użyjesz tego w klasie, którą projektujesz - użyłbym rekordów.

ZASTRZEŻENIE: Jestem głównym współpracownikiem Projektu Lombok.

— rzwitserloot
źródło