Tworzenie klas-potworków z wykorzystaniem Lomboka

Lombok wzbudza wiele emocji. Tych pozytywnych jak i negatywnych. Ma on wiele zalet, ale nie jest też wolny od wad. Na pewno nie można powiedzieć o Lomboku, iż przechodzi bez echa wśród programistów Java. W wielu sytuacjach jego funkcjonalności dają efekt pozytywny jak i negatywny. Weźmy na przykład na tapet @RequiredArgsConstructor. Dzięki niemu nie musimy tworzyć na nowo konstruktora, gdy dochodzi nam kolejne finalne pole w klasie. Natomiast na drugim biegunie jest to, iż takie podejście zwalnia programistów z myślenia. Z tego powodu zdarza się sytuacja, iż kończymy w projekcie z klasą z nastoma zależnościami…

Jednak dzisiaj nie o tym. W tym wpisie chciałem się skupić na innym specyficznym problem, który możemy napotkać korzystając z Lomboka wszędzie, bez zastanowienia.

Przypadek z życia wzięty

Załóżmy, iż mamy klasę, która agreguje nam jedną wartość np. markę samochodu. Pierwsze co przychodzi na myśl to skorzystanie ze wzorca Value Object. No dobra, zróbmy tak.

package io.cezarysanecki.vo; import lombok.EqualsAndHashCode; import lombok.RequiredArgsConstructor; @EqualsAndHashCode @RequiredArgsConstructor public final class VehicleMake { private final String value; }

Wykorzystaliśmy Lomboka do stworzenia naszej klasy reprezentującej daną wartość. Wszystko super. Teraz nie będziemy wszędzie przekazywać String i domyślać się co to reprezentuje po nazwie zmiennej. Z nowym podejściem na pierwszy rzut oka widać jaki typ parametru należy podać.

Załóżmy teraz, iż komuś nie podoba się korzystanie z new. Dla niego lepsze jest skorzystanie z buildera. Lombok daje nam taką możliwość za małą cenę w postaci adnotacji @Builder. Zobaczmy jak to wygląda.

package io.cezarysanecki.vo; import lombok.Builder; import lombok.EqualsAndHashCode; import lombok.RequiredArgsConstructor; @Builder @EqualsAndHashCode @RequiredArgsConstructor public final class VehicleMake { private final String value; }

No i super. Teraz możemy tworzyć obiekty tej klasy na dwa sposoby.

VehicleMake vehicleMakeNew = new VehicleMake("skoda"); VehicleMake vehicleMakeBuilder = VehicleMake.builder() .value("skoda") .build();

Oczywiście umyślnie pominąłem konstrukcję @RequiredArgsConstructor(staticName = "of"). To rozwiązanie również powodowałaby zamieszanie, do którego zmierzam.

Problem na produkcji

Nasze rozwiązanie się przyjęło. Testy przeszły, więc wrzucamy je na produkcję. Zadowoleni kończymy ciężki dzień pracy. Jednak po jakiś dwóch dniach wpada nam błąd związany z tą funkcjonalnością. Po krótkiej analizie weryfikujemy, iż coś nie tak dzieje się z poniższą linijką kodu.

//obie zmienne są typy VehicleMake firstVehicleMake.equals(secondVehicleMake);

Wynikiem tej operacji powinna być wartość true, ponieważ obydwie wartości odnoszą się do marki Skoda. Po zajrzeniu głębiej dowiadujemy się, iż o ile u nas w aplikacji wartość to "skoda" to z zewnętrznego systemu otrzymaliśmy "SKODA". Stąd ten zgrzyt.

Pierwsze co może przyjść na myśl to szybkie rozwiązanie sytuacji przez wykorzystanie porównania wartości przez equalsIgnoreCase.

package io.cezarysanecki.vo; import lombok.Builder; import lombok.EqualsAndHashCode; import lombok.Getter; import lombok.RequiredArgsConstructor; @Getter @Builder @EqualsAndHashCode @RequiredArgsConstructor public final class VehicleMake { private final String value; } //... firstVehicleMake.getValue().equalsIgnoreCase(secondVehicleMake.getValue());

Dobrze wiemy, iż to jednak nie tędy droga… Moglibyśmy zrezygnować z @EqualsAndHashCode i nadpisać equals, aby nie zwracał uwagi na wielkość liter. Byłoby to faktycznie prawidłowe. Jednak z jakiegoś powodu, w celach audytowych, chcemy mieć unifikację wartości w bazie danych. Przyjmujemy z tego powodu, iż wszystko będzie zapisywane wielkimi literami. No to lecimy z poprawką do kodu.

Kończymy z potworkiem

Rozwiązanie mogłoby wyglądać w następujący sposób. Wykorzystując możliwość nadpisywania metod z buildera oraz tworząc metodę wytwórczą kończymy z takim oto potworkiem (bez @RequiredArgsConstructor, bo musieliśmy sami stworzyć pasujący konstruktor). Oczywiście wszystko działa jak należy. Jednak czy jesteśmy z siebie finalnie zadowoleni?

package io.cezarysanecki.vo; import lombok.Builder; import lombok.EqualsAndHashCode; @Builder @EqualsAndHashCode public final class VehicleMake { private final String value; public VehicleMake(String value) { validateValue(value); this.value = value.toUpperCase(); } public static class VehicleMakeBuilder { public VehicleMakeBuilder value(String value) { validateValue(value); this.value = value.toUpperCase(); return this; } } private static void validateValue(String value) { if (value == null || value.isBlank()) { throw new IllegalStateException("value must be present"); } } }

Przykład z tego artykułu to prawdziwa historia. Może moglibyśmy tego uniknąć, gdyby tak nie skupiać się w 100% na Lomboku, a go sobie po prostu w tym przypadku… odpuścić? Można by skończyć z czymś o wiele przyjemniejszym dla oka.

package io.cezarysanecki.vo; import java.util.Objects; public final class VehicleMake { private final String value; private VehicleMake(String value) { if (value == null || value.isBlank()) { throw new IllegalStateException("value must be present"); } this.value = value.toUpperCase(); } public static VehicleMake of(String value) { return new VehicleMake(value); } @Override public boolean equals(Object o) { if (this == o) return true; if (o == null || getClass() != o.getClass()) return false; VehicleMake that = (VehicleMake) o; return Objects.equals(value, that.value); } @Override public int hashCode() { return Objects.hash(value); } }

Ewentualnie skorzystać z @EqualsAndHashCode jeżeli ktoś nie chce mieć tego boilerplate kodu.

package io.cezarysanecki.vo; import lombok.EqualsAndHashCode; @EqualsAndHashCode public final class VehicleMake { private final String value; private VehicleMake(String value) { if (value == null || value.isBlank()) { throw new IllegalStateException("value must be present"); } this.value = value.toUpperCase(); } public static VehicleMake of(String value) { return new VehicleMake(value); } }

Podsumowanie

Czasami narzędzia potrafią nami zawładnąć i doprowadzić nas do tworzenia nieczytelnego kodu. Nie można im się tak po prostu dać. Trzeba wpadać samemu na najlepsze i najczytelniejsze rozwiązania w oparciu o nie.

Istotna jest również komunikacja w zespole, aby zwracać uwagę na takie rzeczy. Dodatkowo można wypracować wspólne konwencje, iż np. Value Object tworzymy tylko przez metodę wytwórczą of. Nie ma możliwości korzystania jawnie z konstruktorów poza klasą czy też z builderów. Przyjmujemy to postanowienie za standard i za nim podążamy. Na review do checklisty dodajemy sobie kolejny punkt, aby na takie rzeczy zwracać uwagę aż nie wejdą one w krew.

Jaki jest Twój stosunek do Lomboka? Czy korzystasz z niego na projekcie? jeżeli tak, to czy też miałeś/aś interesujące historie z nim związane?