Annotations. Partie 2. Lombok

Annotations. Partie 1 — un peu ennuyeuse Dans cette partie, j'ai décidé d'aborder la bibliothèque Lombok, car c'est un représentant bien connu des annotations de code source. J'aborderai les annotations d'exécution dans le prochain article. Il était une fois un programmeur Java. Chaque jour, elle écrivait du code ordinaire, par exemple, comme celui-ci :

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 +
                '}';
    }
}

Cette classe est ordinaire — seulement 2 champs (après tout, il y a parfois plus de 10 à 15 champs). Bien entendu, tout cela peut être généré dans l’EDI. Mais bon sang, ça prend sa place. S'il y a 15 à 20 champs, chacun d'eux a besoin de getters, de setters, de constructeurs... Parmi tout cela, quelques autres méthodes, invisibles à l'œil nu, pourraient facilement être perdues. Comment pouvons-nous aider ce programmeur à écrire plus vite et moins ? Lombok. Hors de la poêle et dans le feu avec vous. Voici la même classe, mais maintenant nous utilisons Lombok :

package lombok;

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

C'est tout. Cool hein? À quoi sert l' annotation @Data ? Lors de la compilation, cette annotation génère des getters/setters pour tous les champs et remplace toString(), equals() et hashCode() selon les règles standard. Vous pouvez installer le plugin dans l'EDI. Il verra toutes les méthodes qui n’ont pas encore été créées. À ce stade, j'espère que vous, mon lecteur, êtes devenu intéressé, car ce qui suit sera une brève introduction avec des liens vers des détails. Lombok vous permet également de personnaliser la génération de code, par exemple tous les getters et setters ne sont pas toujours nécessaires, ou vous aurez peut-être besoin d'un algorithme différent pour générer un code de hachage. Pour ce faire, il existe des annotations distinctes (je pense que beaucoup d'entre elles n'auront pas besoin d'une description) : @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor et @AllArgsConstructor, @Log . commun. L'ensemble peut être vu ici . Portez une attention particulière à var et val. Cela signifie que vous pouvez écrire du code comme ceci :

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);
    }
}

Pourquoi est-ce nécessaire ? Par exemple, nous avons une classe RandomAccessFileChannel. Pourquoi voudrions-nous écrire du code comme celui-ci ?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Si on peut faire ça ?

var channel2 = new RandomAccessFileChannel();

À mon avis, ce n'est pas toujours acceptable. Par exemple, nous avons une méthode maléfique qui renvoie une carte maléfique :

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

Si vous l'appelez ainsi :

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

Ensuite, il est plus ou moins clair avec quoi nous travaillons. Si l'appel ressemble à ceci :

var listSetMap = evilMap();

alors seul le diable sait ce que evilMap() y retournera, et jusqu'à ce que vous regardiez la méthode elle-même, vous ne le savez pas. Pourquoi courir autour des fichiers sources ? En général, vous devez être prudent avec cela. Branche expérimentale : je souhaite mentionner ici l' annotation @UtilityClass . Il crée un constructeur privé qui lève une exception (afin que les petites mains sales n'utilisent pas la réflexion pour s'en mêler). Et c'est très beau au début d'un cours — ça nous dit qu'il existe des méthodes utilitaires. L' annotation @Delegate implémente le modèle de délégation. Supposons que vous ayez une classe qui délègue quelque chose à une autre classe et que vous apportiez des modifications à certaines méthodes seulement - cette annotation vous évitera de dupliquer les méthodes et en gardera une trace. Si vous supprimez ou ajoutez une méthode, cette annotation le remarquera. Branche d'annotations expérimentales Site officiel de GitHub Pour que l'EDI fonctionne correctement avec Lombok et ne souligne pas les méthodes comme inexistantes, vous devez installer le plugin. Le site officiel comporte une section de configuration où vous pouvez voir comment connecter le plugin pour chaque IDE. Comme vous pouvez le constater, le lombok est populaire : >5 000 étoiles et >1 000 fourchettes. Spring utilise le lombok dans ses cours. Si vous avez Spring dans votre projet, jetez-y un œil : il a peut-être attiré Lombok à votre insu.