Anotaciones. Parte 2. Lombok

Anotaciones. Parte 1: un poco aburrida En esta parte, decidí tocar la biblioteca Lombok, ya que es un conocido representante de las anotaciones del código fuente. Me ocuparé de las anotaciones en tiempo de ejecución en el próximo artículo. Anotaciones. Parte 2. Lombok - 1

Érase una vez un programador de Java. Todos los días escribía código normal, por ejemplo, como este:

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 clase es normal: sólo 2 campos (después de todo, a veces hay más de 10 a 15 campos). Por supuesto, todo esto se puede generar en el IDE. Pero maldita sea, eso ocupa su lugar. Si hay entre 15 y 20 campos, cada uno de ellos necesita captadores, definidores, constructores... Entre todos estos, un par de métodos más, invisibles a la vista, podrían perderse fácilmente. ¿Cómo ayudamos a este programador a escribir más rápido y menos? Lombok. De la sartén al fuego contigo. Aquí está la misma clase, pero ahora usamos Lombok:

package lombok;

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

Eso es todo. Genial, ¿eh? ¿ Qué hace la anotación @Data ? Durante la compilación, esta anotación genera captadores/definidores para todos los campos y anula toString(), equals() y hashCode() de acuerdo con las reglas estándar. Puede instalar el complemento en el IDE. Verá todos los métodos que aún no se hayan creado. Anotaciones. Parte 2. Lombok - 2

En este punto, espero que usted, mi lector, se haya interesado, porque lo que sigue será una breve introducción con enlaces a detalles. Lombok también le permite personalizar la generación de código; por ejemplo, no siempre se necesitan todos los getters y setters, o puede que necesite un algoritmo diferente para generar un código hash. Para lograr esto, hay anotaciones separadas (creo que muchas de ellas no necesitarán una descripción): @Getter/@Setter, @ToString, @EqualsAndHashCode, @NoArgsConstructor, @RequiredArgsConstructor y @AllArgsConstructor, @Log. Estas son las más común. Todo el conjunto se puede ver aquí . Preste especial atención a var y val. Esto significa que puedes escribir 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 qué es esto necesario? Por ejemplo, tenemos una clase RandomAccessFileChannel. ¿Por qué querríamos escribir código como este?

RandomAccessFileChannel channel = new RandomAccessFileChannel();

¿Si podemos hacer esto?

var channel2 = new RandomAccessFileChannel();

En mi opinión, esto no siempre es aceptable. Por ejemplo, tenemos un método malvado que devuelve un mapa malvado:

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

Si lo llamas así:

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

Entonces queda más o menos claro con qué estamos trabajando. Si la llamada es así:

var listSetMap = evilMap();

entonces sólo el diablo sabe qué devolverá evilMap() allí, y hasta que no mires el método en sí, no lo sabrás. ¿Por qué andar recorriendo los archivos fuente? En general, hay que tener cuidado con esto. Rama experimental: aquí quiero mencionar la anotación @UtilityClass . Crea un constructor privado que genera una excepción (para que las manitas sucias no utilicen el reflejo para entrometerse allí). Y es muy bonito al comienzo de una clase: nos dice que existen métodos de utilidad. La anotación @Delegate implementa el patrón de delegación. Suponga que tiene una clase que delega algo a otra clase y realiza cambios solo en algunos de los métodos; esta anotación le evitará duplicar métodos y los mantendrá al tanto. Si elimina o agrega un método, esta anotación se notará. Rama de anotaciones experimentales Sitio web oficial de GitHub Para que el IDE funcione correctamente con lombok y no resalte los métodos como inexistentes, debe instalar el complemento. El sitio web oficial tiene una sección de configuración donde puedes ver cómo conectar el complemento para cada IDE. Como puedes ver, el lombok es popular: >5.000 estrellas y >1.000 tenedores. Spring usa lombok en sus clases. Si tiene Spring en su proyecto, eche un vistazo: es posible que haya incorporado lombok sin su conocimiento.