Annotazioni. Parte 2. Lombok

Annotazioni. Parte 1: un po' noiosa In questa parte ho deciso di toccare la libreria Lombok, poiché è una nota rappresentante delle annotazioni del codice sorgente. Affronterò le annotazioni di runtime nel prossimo articolo. C'era una volta un programmatore Java. Ogni giorno scriveva codice ordinario, ad esempio, in questo modo:

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

Questa classe è ordinaria: solo 2 campi (dopo tutto, a volte ci sono più di 10-15 campi). Naturalmente tutto questo può essere generato nell'IDE. Ma dannazione, quello prende il suo posto. Se i campi sono 15-20, ognuno di essi necessita di getter, setter, costruttori... Tra tutti questi, un paio di altri metodi, invisibili alla vista, potrebbero facilmente andare perduti. Come possiamo aiutare questo programmatore a scrivere più velocemente e meno? Lombok. Fuori dalla padella e nel fuoco con te. Ecco la stessa classe, ma ora usiamo Lombok:

package lombok;

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

È tutto. Splendido, no? Cosa fa l' annotazione @Data ? Durante la compilazione, questa annotazione genera getter/setter per tutti i campi e sovrascrive toString(), equals() e hashCode() in base alle regole standard. È possibile installare il plugin nell'IDE. Vedrà tutti i metodi che non sono ancora stati creati. A questo punto spero che tu, mio ​​lettore, ti sia interessato, perché quella che segue sarà una breve introduzione con collegamenti ai dettagli. Lombok ti consente anche di personalizzare la generazione del codice, ad esempio tutti i getter e setter non sono sempre necessari, oppure potresti aver bisogno di un algoritmo diverso per generare un codice hash. Per fare ciò, ci sono annotazioni separate (penso che molte di loro non avranno bisogno di una descrizione): @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor e @AllArgsConstructor, @Log Queste sono le più comune. L'intero set può essere visto qui . Prestare particolare attenzione a var e val. Ciò significa che puoi scrivere codice come questo:

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

Perché è necessario? Ad esempio, abbiamo una classe RandomAccessFileChannel. Perché dovremmo voler scrivere un codice come questo?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Se possiamo farlo?

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

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

var listSetMap = evilMap();

allora solo il diavolo sa cosa evilMap() restituirà lì, e finché non guardi il metodo stesso, non lo sai. Perché andare in giro tra i file sorgente? In generale, devi stare attento con questo. Ramo sperimentale: qui voglio menzionare l' annotazione @UtilityClass . Crea un costruttore privato che lancia un'eccezione (quindi le piccole mani sporche non usano la riflessione per intromettersi). Ed è molto bello all'inizio di una lezione: ci dice che esistono metodi di utilità. L' annotazione @Delegate implementa il modello di delega. Supponiamo di avere una classe che delega qualcosa a un'altra classe e di apportare modifiche solo ad alcuni metodi: questa annotazione ti eviterà la duplicazione dei metodi e ne terrà traccia. Se rimuovi o aggiungi un metodo, questa annotazione verrà notata. Ramo annotazioni sperimentali GitHub Sito web ufficiale Affinché l'IDE funzioni correttamente con lombok e non evidenzi metodi come inesistenti, è necessario installare il plug-in. Il sito Web ufficiale ha una sezione di configurazione in cui puoi vedere come collegare il plug-in per ciascun IDE. Come puoi vedere, Lombok è popolare: >5.000 stelle e >1.000 forchette. Spring usa lombok nelle sue lezioni. Se hai la primavera nel tuo progetto, dai un'occhiata: potrebbe aver attirato Lombok a tua insaputa.