Faut il adopter Lombok?

Introduction

Lombok, qui ne connaît pas cet outil? Fallait il vraiment le présenter? Probablement que non car aujourd’hui, il n’existe plus beaucoup de projet java se faisant sans lui !

Mais pourquoi fait il ainsi l’unanimité parmi les développeurs et est ce vraiment une bonne idée de l’utiliser ou du moins qu’est ce que cela nous coûte de le faire?

Dans cet article, après avoir présenté et passer en revue les utilisations courantes  de cet outil, nous essayerons d’en voir les limites si elles existent

Génération

Lombok est un outil d’aide au développeur permettant de compléter un code existant de façon transparente via des annotations. Cette action se réalise de façon caché à la compilation via un processeur d'annotation qui va alors générer le code manquant.

Par exemple

Voici une classe Livre classique:

public class Livre {

    private String name;

    public Livre(String name) {
        this.name = name;
    }

    public String getName()
    {
        return this.name;
    }

    public void setName(String name)
    {
        this.name=name;
    }

    @Override
    public String toString()
    {
        return "Livre(name="+this.name+")";
    }

    @Override
    public boolean equals(Object o) {
        if (this == o) return true;
        if (o == null || getClass() != o.getClass()) return false;
        Livre livre = (Livre) o;
        return name.equals(livre.name);
    }

    @Override
    public int hashCode() {
        return Objects.hash(name);
    }
}

Son équivalent Lombok permet de la simplifier ainsi:

@Getter
@Setter
@AllArgsConstructor
@EqualsAndHashCode
@ToString
public class LivreWithLombok {

    private String name;
}

On notera l’utilisation des annotations @Getter, @Setter, @AllArgsConstructor, @EqualsAndHashCode et @ToString qui vous l’aurez compris permet de faire générer ces méthodes très usuelles. À noter que pour aller encore au plus simple, l’annotation @Data permettra de générer l'équivalent des précédentes annotations.

Ca ne se limite pas à cela, lombok a pour vocation de servir aussi de roue de secour comme dans la gestion des flux en les fermants pour vous avec par exemple l’annotation @CleanUp où de garantir la non nullité sur des passages de paramètres avec @NotNull (mais on sait que personne n’utilise de toute façon le mot clé null).

Il peut aussi faciliter la vie dans la gestion des logs avec l’annotation @Log où @Sl4j, etc...

De même, pour ceux un peu sensible a scala ou qui connaissent les dernières évolutions java (la 10 en l'occurrence) , il est possible avec lombok d’utiliser les mots clefs var et val. Indéniablement Lombok va donc participer à une simplification du code, faciliter sa lecture et donc aussi améliorer les processus de maintenance qui seront à réaliser dessus.

Mais

Ah oui je sais mais n’est pas un signe positif… ba merde au positivisme, mais permet de nuancer… et on va nuancer sur lombok car quand même si cet outil est génial, on peut se demander si ce genre de simplification est toujours une bonne chose.

Parmis les choses simple sur lesquels on peut tout de suite mettre de l’attention c’est l’utilisation des annotations toString et Equals, c’est simple attention aux appels circulaires entre classe. Ces annotations permettent de spécifier où exclure d'éventuelles données membres, n’oubliez pas ce genre de détails.

Mais cela est un point qui n’est que localement technique et si un problème survient, il sera relativement facile à corriger. 

Pourtant il peut y avoir des conséquences qui vont impacter beaucoup plus profondément la conception d’un logiciel et donc de sa maintenance.

Pour entrer dans cette problématique, petite question: est ce que vous programmez en préférant réfléchir votre conception en utilisant des structures de données ou plutôt en suivant les principes de la POO?

Si je pose cette question c’est évidemment parce qu'il y a un rapport avec la philosophie d’utilisation de lombok.

En effet, si l’on reprend le livre de Robert C. Martin [clean-code], au chapitre 6, on pourra trouver les définitions suivantes: Si l’on s'intéresse à ce qu’est la programmation procédurale, celle ci se présente essentiellement sous la forme de l’utilisation de structures de données n'exposent pas de fonction significativement métier, celle-ci étant globalement définies de manières annexe à ces structures. À l’inverse la POO, pousse à la définition d’objet encapsulant et masquant leurs données derrières des abstractions et fournissent explicitement des fonctions métier pour les manipuler.

La subtilité vous paraît floue? Pourtant les deux principes ont des avantages et des inconvénient très différents!

Pour reprendre textuellement Martin:

Un code procédural (basé sur des structures de données) facilite l’ajout de nouvelles fonctions sans modifier les structures existantes. De son côté, un code orienté POO facilite l’ajout de nouvelles classes sans modifier les fonctions existantes.

À l’inverse, la modification d’une structure de données dans un code procédural, aura un impact dans une grande majorité des fonctions manipulant cette structure. Et de même, la modification, ajout, suppression d’une fonction métier aura la aussi un impact majeur sur l’ensemble des classes.

La distinction est plus claire? On se rend même compte que les deux approches sont assez diamétralement opposés! Et le choix d’utiliser l’un ou l’autres est largement conditionné par la stabilité soit des données soit des comportements.

Pour en revenir à lombok dont l'annotation principal et la plus utilisé est surement @Data… A votre avis quel paradigme s’accorde le plus avec ?

A mon sens il s’agit de l’approche procedural. C’est à dire le type d’application qui nécessite de faire évoluer des besoins métiers en terme de fonction mais où les structures de données seront stable dans le temps.

Du coup dans une approche orienté objet, on peut alors se demander la pertinence de l’utilisation de lombok. Bien sur d’autres annotations utiles sont présent dans lombok comme celle gérant les logs mais est ce que cela justifie son utilisation systématique? Et surtout (et c’est surement la question la plus importante) est ce que l’utilisation de lombok ne conditionne pas à avoir systématiquement une réflexion orienté procédurale ?

Références

[projectlombok] https://projectlombok.org/
[lombok-intro] https://dzone.com/articles/introduction-to-lombok?edition=479258&utm_source=Daily%20Digest&utm_medium=email&utm_campaign=Daily%20Digest%202019-05-11
[lombok-rex] https://fxrobin.developpez.com/tutoriels/java/lombok-retour-experience
[lombok-jackson] https://www.thecuriousdev.org/lombok-builder-with-jackson/
[lombok-log] https://projectlombok.org/features/log
[clean-code] Date de publication originale : 1 août 2008, Auteur : Robert C. Martin, ISBN : 9780132350884