Annotazioni. Seconda parte. Lombok

Annotazioni. Prima parte, un po' noiosa In questa parte ho deciso di toccare la biblioteca di Lombok in quanto nota rappresentante delle annotazioni alla fonte. Con annotazioni Runtime nel prossimo articolo. C'era una volta un programmatore java, ogni giorno scriveva un comunissimo codice, ad esempio questo:

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

Questa è una classe tipica con solo 2 campi (ma a volte ci sono più di 10-15 campi). Sì, certo, tutto questo può essere generato nell'IDE, ma dannazione, occupa spazio. Se ci sono 15-20 campi, tutti necessitano di getter, setter, costruttori... In mezzo a tutto questo, un paio di altri metodi invisibili alla vista possono facilmente perdersi. Come posso aiutare un programmatore del genere a scrivere più velocemente e meno? Lombok. Direttamente al caldo, la stessa lezione ma usando Lombok:

package lombok;

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

Sì, questo è tutto. Freddo? Cosa farà l' annotazione @Data ? In fase di compilazione, genererà getter/setter per tutti i campi, toString e ridefinirà equals e hashCode secondo gli standard. Puoi installare un plugin nell'IDE e vedrà tutti i metodi che non sono ancora stati creati. Spero che tu, lettore, lo abbia trovato interessante, perché ciò che segue è una breve introduzione e collegamenti ai dettagli. Lombok offre anche l'opportunità di personalizzare la generazione; non sempre tutti i getter, setter o hashcode devono essere generati in modo diverso. Pertanto, ci sono annotazioni separate (penso che molte di loro non abbiano bisogno di una descrizione) @Getter/@Setter @ToString @EqualsAndHashCode @NoArgsConstructor, @RequiredArgsConstructor e @AllArgsConstructor @Log Queste sono le più tipiche, è possibile visualizzare l'intero set qui var e val meritano un'attenzione particolare. E' possibile scrivere così:

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

Perché è necessario? Ad esempio, abbiamo la classe RandomAccessFileChannel. Bene, perché dobbiamo scriverla in questo modo:

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Se possibile in questo modo:

var channel2 = new RandomAccessFileChannel();

Secondo me questo non è sempre accettabile. Ad esempio, abbiamo un metodo malvagio che restituisce una mappa malvagia:

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

se lo chiami così:

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

È più o meno chiaro con cosa stiamo lavorando. Se la chiamata è così:

var listSetMap = evilMap();

poi chi diavolo sa cosa restituisce evilMap() e finché non guardi il metodo stesso, non lo saprai. Perché preoccuparsi di consultare le fonti? In generale, devi stare più attento con questo. Discussione sperimentale: qui vorrei notare le annotazioni: @UtilityClass Crea un costruttore privato e lancia un'eccezione lì (in modo che le mani sporche di riflessione non entrino qui). E molto bene all'inizio della lezione ci dice che esistono metodi di utilità. @Delegate Implementa il modello di delega. Se hai una classe che delega qualcosa a un'altra classe, apportando modifiche solo ad alcuni metodi, questa annotazione ti eviterà la duplicazione dei metodi e ne terrà traccia. Se un metodo viene rimosso o aggiunto, lo noterà. Thread di annotazioni sperimentali GITHUB Sito web ufficiale Affinché l'IDE funzioni normalmente con lombok e non evidenzi metodi come inesistenti, è necessario installare il plug-in. Sul sito ufficiale c'è una sezione di configurazione dove puoi vedere come collegare il plugin per ciascun IDE. Come puoi vedere, Lombok è popolare. >5000 stelle e >1000 forchette. Spring usa lombok nelle sue lezioni. Se hai una molla nel tuo progetto, cercala, forse ha tirato su il lombok, semplicemente non lo sai.