Anmerkungen. Teil 2. Lombok

Anmerkungen. Teil 1 – etwas langweilig In diesem Teil habe ich beschlossen, auf die Lombok-Bibliothek einzugehen, da sie ein bekannter Vertreter von Quellcode-Annotationen ist. Auf Laufzeitanmerkungen gehe ich im nächsten Artikel ein. Es war einmal ein Java-Programmierer. Jeden Tag schrieb sie gewöhnlichen Code, zum Beispiel so:

package lombok;

public class Person {
    private String name;
    private int age;

    public Person(String name, int age) {
        this.name = name;
        this.age = age;
    }

    public Person() {
    }

    public String getName() {
        return name;
    }

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

    public int getAge() {
        return age;
    }

    public void setAge(int age) {
        this.age = age;
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;

        Person person = (Person) o;

        if (age != person.age) return false;
        return name != null ? name.equals(person.name) : person.name == null;
    }

    @Override
    public int hashCode() {
        int result = name != null ? name.hashCode() : 0;
        result = 31 * result + age;
        return result;
    }

    @Override
    public String toString() {
        return "Person{" +
                "name='" + name + '\'' +
                ", age=" + age +
                '}';
    }
}

Diese Klasse ist gewöhnlich – nur 2 Felder (schließlich gibt es manchmal mehr als 10–15 Felder). Natürlich kann das alles in der IDE generiert werden. Aber verdammt, das nimmt seinen Platz ein. Wenn es 15 bis 20 Felder gibt, benötigt jedes von ihnen Getter, Setter, Konstruktoren ... Unter all diesen könnten leicht einige andere, für das Auge unsichtbare Methoden verloren gehen. Wie können wir diesem Programmierer helfen, schneller und weniger zu schreiben? Lombok. Raus aus der Bratpfanne und rein ins Feuer mit dir. Hier ist die gleiche Klasse, aber jetzt verwenden wir Lombok:

package lombok;

@Data
public class Person {
    private String name;
    private int age;
}

Das ist alles. Cool was? Was bewirkt die @Data- Annotation? Während der Kompilierung generiert diese Annotation Getter/Setter für alle Felder und überschreibt toString(), equal() und hashCode() gemäß den Standardregeln. Sie können das Plugin in der IDE installieren. Es werden alle Methoden angezeigt, die noch nicht erstellt wurden. An dieser Stelle hoffe ich, dass Sie, mein Leser, Interesse geweckt haben, denn es folgt eine kurze Einführung mit Links zu Details. Mit Lombok können Sie auch die Codegenerierung anpassen, z. B. werden nicht immer alle Getter und Setter benötigt, oder Sie benötigen möglicherweise einen anderen Algorithmus, um einen Hash-Code zu generieren. Um dies zu erreichen, gibt es separate Annotationen (ich denke, viele davon benötigen keine Beschreibung): @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor und @AllArgsConstructor, @Log Das sind die meisten gemeinsam. Das ganze Set gibt es hier zu sehen . Achten Sie besonders auf var und val. Das bedeutet, dass Sie Code wie diesen schreiben können:

package lombok;

import lombok.experimental.var;

@Data
public class Person {
    private String name;
    private int age;

    public static void main(String[] args) {
        var person = new Person();
        person.setAge(22);
        System.out.println(person);
    }
}

Warum ist das notwendig? Zum Beispiel haben wir eine RandomAccessFileChannel-Klasse. Warum sollten wir solchen Code schreiben wollen?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Wenn wir das schaffen?

var channel2 = new RandomAccessFileChannel();

Meiner Meinung nach ist dies nicht immer akzeptabel. Zum Beispiel haben wir eine böse Methode, die eine böse Karte zurückgibt:

public static Map<List<Set<Integer>>, Set<List<String>>> evilMap() {
    return new HashMap<>();
}

Wenn man es so nennt:

Map<List<Set<Integer>>, Set<List<String>>> listSetMap = evilMap();

Dann ist mehr oder weniger klar, womit wir arbeiten. Wenn der Anruf so abläuft:

var listSetMap = evilMap();

Dann weiß nur der Teufel, was evilMap() dort zurückgeben wird, und bis man sich die Methode selbst anschaut, weiß man es nicht. Warum die Quelldateien durchgehen? Im Allgemeinen müssen Sie dabei vorsichtig sein. Experimenteller Zweig: Hier möchte ich die Annotation @UtilityClass erwähnen . Es erstellt einen privaten Konstruktor, der eine Ausnahme auslöst (damit sich schmutzige kleine Hände nicht mit Reflektion dort einmischen). Und es ist sehr schön zu Beginn eines Kurses – es sagt uns, dass es nützliche Methoden gibt. Die Annotation @Delegate implementiert das Delegationsmuster. Angenommen, Sie haben eine Klasse, die etwas an eine andere Klasse delegiert, und Sie nehmen Änderungen nur an einigen Methoden vor – diese Annotation erspart Ihnen das Duplizieren von Methoden und behält den Überblick. Wenn Sie eine Methode entfernen oder hinzufügen, wird diese Anmerkung darauf hingewiesen. Zweig „Experimentelle Annotationen “ Offizielle GitHub- Website Damit die IDE ordnungsgemäß mit Lombok funktioniert und Methoden nicht als nicht vorhanden hervorgehoben werden, müssen Sie das Plugin installieren. Auf der offiziellen Website gibt es einen Setup- Bereich, in dem Sie sehen können, wie Sie das Plugin für jede IDE verbinden. Wie Sie sehen, ist Lombok beliebt: >5.000 Sterne und >1.000 Gabeln. Spring verwendet Lombok in seinen Klassen. Wenn Sie Spring in Ihrem Projekt haben, werfen Sie einen Blick darauf – möglicherweise hat es Lombok ohne Ihr Wissen eingebunden.