Anotações. Parte dois. Lombok

Anotações. Parte um, um pouco chata Nesta parte, decidi abordar a biblioteca Lombok como um conhecido representante das anotações Source. Com anotações de tempo de execução no próximo artigo. Era uma vez um programador java, todos os dias ele escrevia código comum, por exemplo este:

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

Esta é uma classe típica com apenas 2 campos (mas às vezes há mais de 10 a 15 campos). Sim, claro, tudo isso pode ser gerado no IDE, mas caramba, ocupa espaço. Se houver 15-20 campos, todos eles precisam de getters, setters, construtores... Entre tudo isso, alguns outros métodos que são invisíveis aos olhos podem facilmente se perder. Como posso ajudar esse programador a escrever mais rápido e menos? Lombok. Direto para o calor, a mesma aula mas usando Lombok:

package lombok;

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

Sim, isso é tudo. Legal? O que a anotação @Data fará ? Na fase de compilação, irá gerar getters/setters para todos os campos, toString e redefinir equals e hashCode de acordo com os padrões. Você pode instalar um plugin no IDE e ele verá todos os métodos que ainda não foram criados. Espero que você, leitor, tenha achado interessante, pois o que se segue é uma breve introdução e links para detalhes. Lombok também oferece a oportunidade de personalizar a geração; todos os getters, setters ou hashcodes nem sempre precisam ser gerados de forma diferente. Portanto, existem anotações separadas (acho que muitas delas não precisam de descrição) @Getter/@Setter @ToString @EqualsAndHashCode @NoArgsConstructor, @RequiredArgsConstructor e @AllArgsConstructor @Log Estas são as mais típicas, todo o conjunto pode ser visualizado aqui var e val merecem atenção especial. É possível escrever assim:

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

Por que isso é necessário? Por exemplo, temos a classe RandomAccessFileChannel. Bem, por que precisamos escrevê-la assim:

RandomAccessFileChannel channel = new RandomAccessFileChannel();

Se possível assim:

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

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

var listSetMap = evilMap();

então quem sabe o que evilMap() retorna, e até você olhar o método em si, você não saberá. Por que se preocupar em consultar as fontes? Em geral, você precisa ter mais cuidado com isso. Tópico experimental: Aqui eu gostaria de anotar as anotações: @UtilityClass Ele cria um construtor privado e lança uma exceção lá (para que as mãos sujas de reflexão não entrem aqui). E muito bem no início da aula nos diz que existem métodos utilitários. @Delegate Implementa o padrão de delegação. Se você tiver uma classe que delega algo para outra classe, enquanto faz alterações apenas em alguns métodos, esta anotação evitará que você duplique métodos + os acompanhará. Se um método for removido ou adicionado, ela notará isso. Tópico de anotações experimentais GITHUB Site oficial Para que o IDE funcione normalmente com o lombok, e não destaque os métodos como inexistentes, é necessário instalar o plugin. No site oficial há 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 uma mola no seu projeto, procure, talvez tenha puxado o lombok, você simplesmente não sabe.