Anotações. Parte 2. Lombok

Anotações. Parte 1 — um pouco chata Nesta parte, decidi abordar a biblioteca Lombok, pois ela é uma conhecida representante de anotações de código-fonte. Abordarei as anotações de tempo de execução no próximo artigo. Era uma vez um programador Java. Todos os dias ela escrevia código comum, por exemplo, assim:

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

Esta classe é comum - apenas 2 campos (afinal, às vezes há mais de 10 a 15 campos). Claro, tudo isso pode ser gerado no IDE. Mas, caramba, isso toma o seu lugar. Se houver de 15 a 20 campos, cada um deles precisa de getters, setters, construtores... Entre todos esses, alguns outros métodos, invisíveis aos olhos, podem ser facilmente perdidos. Como podemos ajudar este programador a escrever mais rápido e menos? Lombok. Saia da frigideira e vá para o fogo com você. Aqui está a mesma classe, mas agora usamos Lombok:

package lombok;

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

Isso é tudo. Legal né? O que a anotação @Data faz? Durante a compilação, esta anotação gera getters/setters para todos os campos e substitui toString(), equals() e hashCode() de acordo com as regras padrão. Você pode instalar o plugin no IDE. Ele verá todos os métodos que ainda não foram criados. Neste ponto, espero que você, meu leitor, tenha se interessado, pois o que se segue será uma breve introdução com links para detalhes. Lombok também permite personalizar a geração de código, por exemplo, todos os getters e setters nem sempre são necessários, ou você pode precisar de um algoritmo diferente para gerar um código hash. Para fazer isso, existem anotações separadas (acho que muitas delas não precisarão de uma descrição): @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor e @AllArgsConstructor, @Log Estas são as mais comum. Todo o conjunto pode ser visto aqui . Preste atenção especial a var e val. Isso significa que você pode escrever código como este:

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

Por que isso é necessário? Por exemplo, temos uma classe RandomAccessFileChannel. Por que quereríamos escrever um código como este?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Se pudermos fazer isso?

var channel2 = new RandomAccessFileChannel();

Na minha opinião, isso nem sempre é aceitável. Por exemplo, temos um método maligno que retorna um mapa maligno:

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

Se você chamar assim:

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

Então fica mais ou menos claro com o que estamos trabalhando. Se a chamada for assim:

var listSetMap = evilMap();

então só o diabo sabe o que evilMap() retornará lá, e até você olhar o método em si, você não sabe. Por que contornar os arquivos de origem? Em geral, você precisa ter cuidado com isso. Ramo experimental: quero mencionar aqui a anotação @UtilityClass . Ele cria um construtor privado que lança uma exceção (para que mãozinhas sujas não usem reflexão para se intrometer nisso). E é muito bonito no início da aula — nos diz que existem métodos utilitários. A anotação @Delegate implementa o padrão de delegação. Suponha que você tenha uma classe que delega algo para outra classe e faça alterações apenas em alguns dos métodos — essa anotação evitará que você duplique métodos e os controlará. Se você remover ou adicionar um método, esta anotação será notada. Ramo de anotações experimentais Site oficial do GitHub Para que o IDE funcione corretamente com o lombok e não destaque os métodos como inexistentes, você deve instalar o plugin. O site oficial possui uma seção de configuração onde você pode ver como conectar o plugin para cada IDE. Como você pode ver, o lombok é popular: >5.000 estrelas e >1.000 garfos. Spring usa lombok em suas aulas. Se você tem Spring em seu projeto, dê uma olhada - ele pode ter puxado o lombok sem o seu conhecimento.