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

Livre sur Scala

Je cherchais un bon livre sur Scala, assez technique qui ne soit par une redite des concepts de base de l'informatique mais permette de comprendre les points forts du langage, et bien celui ci honore ses promesses : rapide, synthétique et clair.

Je ne m'attarde pas car de toute façon je reviendrais sur ce langage dans de futurs articles.

SOLID

Aujourd'hui avec un court article, nous allons traiter d'un acronyme. L'acronyme en question est SOLID. Il s'agit d'un acronyme traitant des 5 recommandations de base les plus importantes de la programmation orienté objet [1].

Ainsi l'acronyme signifie:

S pour Single responsibility principle, signifiant qu'une entité ne doit avoir qu'une seul préoccupation et donc ne répondre qu'à une problématique. Cela suit le principe d'analyse en décomposition permettant de dissocier chacun des éléments du système. Généralement ce principe s'applique en premier lieu aux classes (en POO) cependant il est largement admis qu'il est généralisable en l'adaptant au niveau d'abstraction considéré. Ainsi, on retrouvera la même logique sur des composants mais aussi dans les approches de programmation fonctionnelle.

O pour Open/closed principle. Ce principe est à considérer dans la continuité du principe précédent. C'est à dire que si une entité ne considère qu'un seul problème, afin de garantir cette propriété, elle ne doit pas permettre sa modification sinon, soit elle ne répond plus au problème initial soit elle répond a plus que celui ci. Par contre afin de permettre la composition et l'agrégation des fonctions, une entité doit permettre et même faciliter son extension. ainsi en POO on utilisera les mécanismes bien connu d'héritage ou d'encapsulation permettant de compléter ou d'associer des comportements aux sein d'entité dont c'est justement l'unique rôle.

L pour Liskov principle. Rarement violé ce principe impose que les sous types d'une entité doivent continuer à respecter le contrat de base de celle ci et ne pas la transformer, seulement l'étendre. Ainsi grâce à ce principe, la substitution d'une entité par l'un de ses sous types est transparent.

I pour Interface segregation principle. Rejoignant une nouvelle fois le premier principe, celui ci nous pousse à favoriser la construction d'interfaces multiples mais individuelle plutôt qu'une interface agrégeant l'ensemble des contrats à réaliser. Ainsi la maintenabilité s'en trouve augmenté et grâce au précédent principe, une entité bien que potentiellement défaillante selon une interface peut rester fonctionnelle selon une autre (sinon toutes l'auraient été)

D pour Dependency inversion principle est la aussi la continuité du précédemment principe en considérant que les dépendances, si elles sont construite sur les entité les plus abstraites, permettent plus de souplesse dans la construction logiciel et facilite la réorganisation et la substitution en vertue du principe de Liskov. Poussé à son extrême, ce principe nous amènera alors naturellement vers les frameworks permettant l'inversion de contrôle et l'injection de dépendances

Si tout cela n'est pas encore très clair, je vous invite à lire cette petite page qui résume parfaitement SOLID dans la vie quotidienne

Références

[1] http://blog.xebia.fr/2011/07/18/les-principes-solid
[2] http://www.arolla.fr/blog/2017/02/principes-solid-vie-de-jours/