Wstęp do Lomboka – pogromcy niepotrzebnego kodu

Java jest znakomitym językiem programowania, aczkolwiek nie idealnym. Jak wszystko posiada cechy, które zasługują na krytykę. Jednym z największych problemów jest rozwlekłość konstrukcji językowych, które powodują powstawanie czegoś co nazywamy “boilerplate code”. Zanim zaczniemy zajmować się samym Lombokiem, w pierwszej kolejności omówmy co to jest “boilerplate code” i dlaczego jest problemem.

Czym jest “boilerplate code”?

“Boilerplate code” jest to kod, który jest kodem banalnym i powtarzanym w wielu miejscach, ale wciąż wymaganym do poprawnej implementacji. Wydaje się to dziwne, ale rzeczywiście bardzo często kod tego typu jest niezbędny. Idealnym przykładem czegoś takiego są gettery i settery w Javie.

public class LombokTest {
    private Integer id;
    private String name;

    public Integer getId() {
        return id;
    }

    public void setId(Integer id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }
}

Zgodnie z najlepszymi praktykami ukryliśmy pola klasy używając getterów i setterów. Problem w tym, że w tym momencie większość klasy to właśnie “boilerplate”. Kiedy dodamy do klasy standardowe implementacje metod takich jak hashcode() i equals(), to sytuacja pogorszy się jeszcze bardziej…

Lombok jako lekarstwo na rozwleczony kod.

Lombok jest biblioteką, która zawiera w sobie wiele przydatnych narzędzi, które pozwalają tworzyć czystszy kod. Osiągamy to poprzez użycie odpowiednich adnotacji, które zostają przetworzone na etapie kompilacji kodu. Dzięki temu przykład z poprzedniego punktu może wyglądać znacznie lepiej:

@Getter
@Setter
public class LombokTest {
    private Integer id;
    private String name;
}

W tym wypadku klasa też będzie zawierała gettery i settery, ale nie musimy ich tworzyć, ani nawet na nie patrzeć. Taki kod jest znacznie prostszy i przyjemniejszy, a to dopiero początek tego co Lombok potrafi. Omówię w tym momencie najprzydatniejsze adtnotacje.

@EqualsAndHashCode

Ta adnotacja użyta na klasie skutecznie pozbywa się przykrego obowiązku implementacji metod hashcode() and equals(). Jest to świetna rzecz i aż miło jest popatrzeć na klasę, która nie musi posiadać czegoś takiego:

public class LombokTest {
    private Integer id;
    private String name;

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (!(o instanceof LombokTest)) return false;
        LombokTest that = (LombokTest) o;
        return Objects.equals(id, that.id) &&
                Objects.equals(name, that.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(id, name);
    }
}
@ToString

Automatycznie dodaje nam standardową implementację toString(). Ułatwiając logowanie naszych obiektów.

@NoArgsConstructor, @RequiredArgsConstructor, @AllArgsConstructor

Jeśli potrzebujemy standardowego konstruktora to możemy użyć tych adnotacji. Zgodnie z ich nazwą możemy wygenerować konstruktor bezargumentowy, z polami wymaganymi (do ustawanie pól oznaczonych “final”), lub ze wszystkimi polami.

@Data

Ta adnotacja to prawdziwa gwiazda Lomboka. Dzięki niej dostajemy @ToString, @EqualsAndHashCode, @Getter, @Setter, @RequiredArgsConstructor przy użyciu jednej adontacji. Dzięki temu możemy tworzyć klasy typu DTO, które wyglądają fenomenalnie i zawierają wszystko co trzeba.

@Builder

Jeśli lubisz wzorzec budowniczego, ta adnotacja wygeneruje wszystkie potrzebne do tego metody. Od tej pory możesz zapomnieć o mozolnym dodawaniu metod i pól do budowniczego jak dodajesz pole do klasy!

@NonNull

Ta adnotacja zaaplikowana do parametru metody wygeneruje nam automatycznie tzw. “Null Check”. Dzięki temu zapewnimy, że parametr będzie wypełniony, w innych wypadku wołający metodę dostanie NullPointerException.

@Log

Jeśli potrzebujemy użyć loggera aplikacji w naszej klasie, to ta adnotacja sama wygeneruje odpowiednie pole. Dzięki temu możemy użyć loggera bez deklaracji w klasie.

@SneakyThrows

Używanie tej adnotacji jest bardzo kontrowersyjne. Użyta na metodzie pozwala na ominięcie mechanizmu Javy dotyczącego wyjątków. Zwykle wyjątki typu “checked” muszą być obsłużone. Są sytuacje, kiedy ominięcie obsługi pozwala to na uproszczenie kodu, kiedy rzeczywiście obsługa wyjątku nie ma żadnego sensu. Tak czy inaczej nie polecam tej adnotacji. Używanie jej często kończy się nadużyciem i “zabijaniem” wszystkich wyjątków, które jednak powinny być obsłużone.

Zachęcam do obejrzenia reszty funkcjonalności Lomboka na stronie jego twórców.

Podsumowując:

Lombok jest niesamowicie przydatnym narzędziem i gorąco polecam go każdemu. Oszczędności w kodzie uzyskiwanie dzięki Lombokowi są naprawdę bardzo duże. Pasuje to idealnie pod zasady, które są moim zdaniem kluczowe dla systemów IT – KISS i COC.

Leave A Comment