Exile on Keyboard St. - Blog sur Linux et Debian

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Développement

Fil des billets - Fil des commentaires

lundi 6 août 2018

Java: Bien utiliser le Builder pattern

Quand on maintient du code Java, on tombe malheureusement assez souvent sur des méthodes aux signatures complexes comme celle-ci:

public int myMethod(String id, String name, Boolean secure, Object obj, Object backupObj, boolean restart)

Et il n'est pas rare d'avoir encore plus de paramètres !

La situation se dégrade encore quand pour "simplifier", on surcharge la méthode précédente en:

public int myMethod(String id, String name, Boolean secure, Object obj, Object backupObj)

quand restart vaut false puis en:

public int myMethod(String id, String name, Boolean secure, Object obj)

quand en plus backupObj est null.

On peut avoir ainsi 3 à 5 signatures différentes pour la même méthode. Et cela devient vite unsupportable quand on veut refactorer ces méthodes, parce qu'elles sont référencées n fois dans le code de production et également dans les tests.

Si le développeur qui a créé la première méthode avait créé un object et l'avait passé en paramètre de sa méthode, on n'en serait pas là !

Imaginons maintenant la méthode suivante qui permet de créer un utilisateur:

public long create(final String firstName, final String name, final int age)

Elle retourne l'identifiant de l'utilisateur créé. Supposons que l'age n'est pas obligatoire et que l'on souhaite anticiper l'ajout de nouveaux champs pour créer un utilisateur.

On va alors plutôt procéder comme suit:

public long create(final User user)

La classe User commencera comme ceci:

public class User
{
    private long id;
    private String firstName;
    private String lastName;
    private int age;
}

Mais pour créer un utilisateur à passer en paramètre de la méthode create, on va créer un Builder pour construire l'objet User.

Pour cela, on peut installer le Plugin Builder Generator. Un autre plugin est également disponible: Inner Builder.

Après redémarrage d'IDEA, un clic-droit puis Generate propose maintenant l'option "Builder" et on a alors la boite de dialogue suivante:

Capture-CreateBuilder.png

Ici on a choisi un "innerBuilder" afin que le Builder soit une classe interne de l'objet lui même.

On choisit ensuite la liste des champs à inclure, on ne prends pas l'id puisqu'il ne sera pas calculé par l'appelant de la méthode create mais bien par celle-ci:

Capture-Select_Fields_to_Be_Available_in_Builder.png

Et on obtient:


    public static final class UserBuilder
    {
        private String firstName;
        private String lastName;
        private int age;

        private UserBuilder()
        {
        }

        public static UserBuilder anUser()
        {
            return new UserBuilder();
        }

        public UserBuilder withFirstName(String firstName)
        {
            this.firstName = firstName;
            return this;
        }

        public UserBuilder withLastName(String lastName)
        {
            this.lastName = lastName;
            return this;
        }

        public UserBuilder withAge(int age)
        {
            this.age = age;
            return this;
        }

        public User build()
        {
            User user = new User();
            user.lastName = this.lastName;
            user.age = this.age;
            user.firstName = this.firstName;
            return user;
        }
    }

On crée ensuite notre User comme suit:

        final User user = UserBuilder
                    .anUser()
                    .withFirstName("Brian")
                    .withLastName("Kernighan")
                    .build();

Cette façon de faire permet:

  • de faire évoluer l'objet User en changeant un minimum de code
  • de valider les différents champs dans la méthode build

Et les signatures des méthodes ne changent pas.

On peut même éviter de dupliquer les champs de la classe User dans la classe UserBuilder en procédant comme ceci:

public static final class UserBuilder
    {
        private User user;

        private UserBuilder()
        {
            user = new User();
        }

        public static UserBuilder anUser()
        {
            return new UserBuilder();
        }

        public UserBuilder withFirstName(String firstName)
        {
            this.user.firstName = firstName;
            return this;
        }

        public UserBuilder withLastName(String lastName)
        {
            this.user.lastName = lastName;
            return this;
        }

        public UserBuilder withAge(int age)
        {
            this.user.age = age;
            return this;
        }

        public User build()
        {
            return user;
        }
    }

Mais notre générateur ne sait pas le faire :-(

dimanche 29 octobre 2017

IntelliJ IDEA: Quel formatage pour votre code Java

Beaucoup de développeurs, même expérimentés, ne prêtent pas (ou pas assez) attention au formatage du code.

Pourtant, l'utilisation d'un template de formatage de code présente les entre autres les avantages suivants:

  • le code est plus facile à lire
  • Les lignes blanches successives et inutiles sont évitées
  • En Java, le pavé des imports sera toujours cohérent entre les développeurs
  • Il permet de voir facilement les blocs, même ceux ne contenant qu'une instruction
  • Une fois un template de formatage choisi dans une équipe, les conflits à l'update sont évités et les merges facilités

Malheureusement, la plupart des projets de développement n'imposent pas un template de formatage et les développeurs se contentent trop souvent du template par défaut de leur environnement de développement. Et comme tous les développeurs n'utilisent pas le même IDE ...

Eclipse propose par exemple trois templates par défaut, qui tous utilisent des tabulations pour indenter le code ... Pire, le profile "Java Conventions" utilise à la fois des tabulations et des espaces. C'est bien dommage qu'Eclipse propose de formater le code avec des tabulations, ce que très peu de gens font encore. Parait t'il qu'historiquement, ce choix avait pour but de "sauver" de l'espace disque !!! Cette époque là est bien révolue. Enfin, pour modifier la façon de formater le code par défaut d'Eclipse, il faut dupliquer le profile avant de pouvoir le modifier, ce qui n'est pas très commode. IntelliJ IDEA n'impose pas cette restriction.

Dans ce billet, on va quand même dupliquer le profile par défaut d'IntelliJ, pour pouvoir exporter nos paramètres et aussi revenir facilement au profile par défaut.

Interdire la détection de l'indentation existante

Première chose à faire dans IntelliJ IDEA, décocher la case "Detect and use existing file indents for editing". En effet, avec cette option, si un fichier est indenté avec des tabulations, IntelliJ considèrera qu'il faut continuer d'indenter de cette façon !!!

Utiliser EditorConfig ou pas ?

EditorConfig est un format de fichier texte permettant de définir des profiles de formatage de code, via quelques propriétés. Ce format est censé être supporté par de nombreux éditeurs, ce qui est très séduisant. Malheureusement, trop peu de propriétés sont implémentées par exemple par le plugin EditorConfig pour IntelliJ, et on est donc amené à définir le reste du paramétrage dans la configuration standard de l'éditeur. J'y reviendrai peut être dans un billet séparé. Pour l'instant, on va cocher qu'on n'utilise pas EditorConfig.

Onglet 'Tabs and Indents'

On ne change rien dans cette section puisqu'IntelliJ utilise par défaut les espaces pour l'indentation et 4 de plus à chaque bloc. Ce formatage nous convient.

Onglet 'Spaces'

Dans cette section, on va cocher dans la sous-section 'Within' la case 'Array initializer braces', ce qui permet de mieux voir les paramètres dans les appels à log4j ou java.util.logging.

Onglet 'Wrapping and braces'

C'est dans cette section que l'on va modifier le plus de choses.

Concernant la position des accolades, on va adopter le style Allman, c'est à dire positionner les accolades sur la ligne suivante.

Toutes les valeurs de la sous section 'Braces placement' seront donc positionnées à 'Next line'.

Une fois qu'on a fait cela, il est logique:

  • dans 'if() statement' de cocher 'else on new line'
  • dans 'try statement' de cocher 'catch on new line' et 'finally on new line'
  • dans 'do while statement' de cocher 'while on new line'

Enfin, afin que les blocs soient bien visibles, même ceux ne contenant qu'une instruction, on va position à 'always' les propriétés 'Force braces' des sous-sections suivantes:

  • 'if() statement'
  • 'for() statement'
  • 'while() statement'
  • 'do while() statement'

Onglet 'Blank lines'

Dans la sous-section 'Keep maximum blank lines', on positionnera les 3 propriétés suivantes à 1 au lieu de 2:

  • In declarations:
  • In code:
  • Before '{':

En effet, je trouve que trop de lignes blanches n'aide pas à la lisibilité mais nous oblige à scroller.

Onglets 'JavaDoc', 'Imports' et 'Arrangement'

Je ne modifie rien pour l'instant.

Onglet 'Code generation'

Dans la section 'Final modifier' on coche les deux cases:

  • Make generated local variables final
  • Make generated parameters final

Vous pouvez utiliser le Formateur de code Java pour IDEA défini ci-dessous en le téléchargeant avec le lien précédent.

lundi 9 octobre 2017

Disposer de la complétion Bash avec Maven

L'outil de build Maven utilisé pour les projets Java a au moins un inconvénient, à savoir que par défaut aucune complétion n'est proposée dans le Terminal.

Que ce soit pour la liste des cibles ou phases ou des options comme skipTests ou maven.test.skip, dont personne ne se souvient et que tout le monde utilise ... (mai cela est une autre affaire), rien n'est proposé pour aider le développeur que vous êtes.

Heureusement, quelqu'un s'est chargé d'écrire un fichier de complétion Bash pour Maven.

Il suffit d'aller voir le dépôt maven-bash-completion et de copier le fichier de complétion dans /etc/bash.completion.d:

sudo \
    wget https://raw.github.com/dimaj/maven-bash-completion/master/bash_completion.bash \
    --output-document /etc/bash_completion.d/mvn

Vous verrez qu'ensuite, tout est plus agréable. Par exemple les cibles sont proposées quand on appuie sur TAB, exactement comme c'est le cas avec .... un Makefile !!!

- page 1 de 2