Annotations. Deuxième partie. Lombok

Annotations. Première partie, un peu ennuyeuse Dans cette partie, j'ai décidé d'aborder la bibliothèque Lombok en tant que représentante bien connue des annotations Source. Avec les annotations Runtime dans le prochain article. Il était une fois un programmeur Java qui écrivait chaque jour du code ordinaire, par exemple ceci :

package lombok;

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

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

    public Chelovek() {
    }

    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;

        Chelovek chelovek = (Chelovek) o;

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

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

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

Il s'agit d'une classe typique avec seulement 2 champs (mais parfois il y a plus de 10 à 15 champs). Oui, bien sûr, tout cela peut être généré dans l'EDI, mais bon sang, ça prend de la place. S'il y a 15 à 20 champs, ils nécessitent tous des getters, des setters, des constructeurs... Parmi tout cela, quelques autres méthodes invisibles à l'œil nu peuvent facilement se perdre. Comment puis-je aider un tel programmeur à écrire plus vite et moins ? Lombok. Directement en pleine chaleur, le même cours mais en utilisant Lombok :

package lombok;

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

Oui c'est tout. Cool? Que fera l' annotation @Data ? Au stade de la compilation, il générera des getters/setters pour tous les champs, toString et redéfinira equals et hashCode selon les standards. Vous pouvez installer un plugin dans l'EDI et il verra toutes les méthodes qui n'ont pas encore été créées. J'espère que vous, lecteur, l'avez trouvé intéressant, car ce qui suit est une brève introduction et des liens vers des détails. Lombok offre également la possibilité de personnaliser la génération ; tous les getters, setters ou hashcodes n'ont pas toujours besoin d'être générés différemment. Par conséquent, il existe des annotations distinctes (je pense que beaucoup d'entre elles n'ont pas besoin d'une description) @Getter/@Setter @ToString @EqualsAndHashCode @NoArgsConstructor, @RequiredArgsConstructor et @AllArgsConstructor @Log Ce sont les plus typiques, l'ensemble peut être consulté ici var et val méritent une attention particulière. Il est possible d'écrire ainsi :

package lombok;

import lombok.experimental.var;

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

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

Pourquoi est-ce nécessaire ? Par exemple, nous avons la classe RandomAccessFileChannel. Eh bien, pourquoi devons-nous l'écrire comme ceci :

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Si possible comme ceci :

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 tu l'appelles ainsi :

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

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

var listSetMap = evilMap();

alors qui diable sait ce que evilMap() renvoie, et jusqu'à ce que vous regardiez la méthode elle-même, vous ne le saurez pas. Pourquoi s'embêter à parcourir les sources ? En général, vous devez être plus prudent avec cela. Fil expérimental : Ici, je voudrais noter les annotations : @UtilityClass Il crée un constructeur privé et y lève une exception (afin que les mains sales de la réflexion n'entrent pas ici). Et très bien, au début du cours, cela nous indique qu'il existe des méthodes utilitaires. @Delegate Implémente le modèle de délégation. Si vous avez une classe qui délègue quelque chose à une autre classe, tout en apportant des modifications uniquement à certaines méthodes, cette annotation vous évitera de dupliquer les méthodes + en gardera une trace. Si une méthode est supprimée ou ajoutée, elle le remarquera. Fil d'annotations expérimentales Site officiel de GITHUB Pour que l'IDE fonctionne normalement avec Lombok et ne souligne pas les méthodes comme inexistantes, vous devez installer le plugin. Sur le site officiel, il y a une section de configuration où vous pouvez voir comment connecter le plugin pour chaque IDE. Comme vous pouvez le voir, Lombok est populaire. >5 000 étoiles et >1 000 fourchettes. Spring utilise le lombok dans ses cours. Si vous avez un ressort dans votre projet, écoutez, peut-être qu'il a arraché le lombok, vous ne le savez tout simplement pas.