Netapsys Blog

TDD : Test Driven Development 2/2 - Mise en pratique

Ludovic Chaboud-Paupi — Mon, 20 May 2013 08:31:00 +0200

Dans le post précédent TDD : Test Driven Development 1/2 - Principes, nous avons vu les principes théoriques du Test Driven Development.

Nous allons maintenant mettre en pratique le cycle de développement du TDD.

Pour rappel, les étapes du cycle du TDD sont :

Définir la fonctionnalité à l'aide du test => Le test est en échec
Implémenter => Le test est en succès, la couverture est à 100%
Réécrire / Simplifier => Le test est en succès, la couverture est à 100%

Nous allons voir dans ce post une mise en pratique du TDD avec comme exemple le workflow d'un article d'un blog.

Exemple : workflow d'un article

création / enregistrement de l'article
transfert pour validation
publication de l'article

Voyons comment réaliser la création et l'enregistrement de l'article en TDD.

Fonctionnalité 1 : Création d'un article vide

TDD - Etape 1 : Définir la fonctionnalité

La fonctionnalité est définie par le test qui doit être unitaire.

Nous nous focalisons sur le but de la fonctionnalité qui est ici de créer un article. Nous nous isolons de contexte technique et des autres fonctionnalités à l'aide de "bouchons".

Nous commençons par écrire un test pour définir la fonctionnalité sans écrire de code d'implémentation.

Test : création d'un article

public class CreationArticleTest {
 @Test
 public void testCreationDUnArticleVide() {
   // Given
   ArticleService articleService = new ArticleServiceImpl();
   // When
   Article article = articleService.creerArticleVide();
   // Then
   assertNotNull(article);
 }
}

Nous avons défini le contrat de notre première fonctionnalité : créer un article vide.

Ce test ne compile car il manque les classes d'implémentation.

Dans le cycle du TDD, nous venons de terminer la première étape : définir le contrat de l'implémentation, c'est à dire ce que doit faire notre programme.

TDD - Étape 2 : Définir l'implémentation

Nous passons à la deuxième étape : définir l'implémentation jusqu'à ce que le test passe.

Création des classes, interfaces et méthodes manquantes

Pour cela nous allons nous servir du code écrit dans le test pour créer l'implémentation manquante.

Les classes et les méthodes manquantes sont indiquées en rouge et en erreur par l'IDE eclipse.

Durant cette étape, nous créons ainsi la classe Article, l'interface et la classe d'implémentation du service ArticleService.

Classe Article

public class Article {
}

Interface ArticleService

public interface ArticleService {
 Article creerArticleVide();
}

Classe ArticleServiceImpl

public class ArticleServiceImpl  implements ArticleService {
 public Article creerArticleVide() {
   return new Article();
 }
}

L'exécution du test est maintenant en succès.

Le plugin eclemma pour eclipse nous indique que la couverture du test est à 100% : tout ce que nous venons de créer était nécessaire au test, nous n'avons rien ajouté d'inutile pour répondre au contrat de notre fonctionnalité.

Couverture du test

Couverture du projet

La couverture du projet est à 100% :

Nous venons de terminer la deuxième étape dans le cycle du TDD : définir l'implémentation jusqu'à ce que le test soit en succès, avec une couverture à 100%.

TDD - Étape 3 : Réécrire le code pour simplifier et réorganiser

Cette étape consiste à simplifier ou à réorganiser le code existant avec les modifications que nous venons d'effectuer.

Ceci peut être par exemple de factoriser du code dupliqué, de simplifier des boucles de traitement ou les conditions des tests.

Par contre il ne s'agit pas de réécrire toute l'implémentation existante. Pour nous limiter dans cette étape, nous ne devons pas modifier les tests existants.

Le code dans notre exemple étant simple, nous n'avons pas besoin d'effectuer de réécriture.

Nous avons terminé la première fonctionnalité et nous pouvons passer à la fonctionnalité suivante.

Fonctionnalité 2 : Enregistrement de l'article

TDD - Étape 1 : Définir la fonctionnalité

Suite à la fonctionnalité de création de l'article, nous souhaitons maintenant enregistrer cet article avec un nom d'auteur, un titre, un contenu. La date d'enregistrement sera définie automatiquement sur l'article.

Nous imposons ce contrat dans notre test unitaire d'enregistrement d'article.

Test : enregistrement d'un article

@Test
public void testEnregistrementDUnArticle() {
 // Given
 Article article = new Article();
 article.setAuteur("test auteur");
 article.setTitre("test titre");
 article.setContenu("test contenu");
 
 ArticleServiceImpl articleServiceImpl = new ArticleServiceImpl();
 ArticleService articleService = articleServiceImpl;

 ArticleDAO articleDAO = Mockito.mock(ArticleDAO.class);
 articleServiceImpl.setArticleDAO(articleDAO);
 
 // When
 articleService.save(article);
 
 // Then
 assertNotNull(article.getDateEnregistrement()); 
 Mockito.verify(articleDAO).save(article);
}

Nous venons d'écrire le contrat correspondant à notre fonctionnalité.

Dans notre test, nous nous sommes focalisés sur l'intention de la fonctionnalité et non sur l'aspect technique. Pour cela nous avons utilisé des "bouchons" à l'aide de "mocks" via Mockito.

Nous nous concentrons ainsi sur le plus important : le code métier qui répond aux règles métier. Nous verrons l'aspect technique plus tard.

Ici la gestion de la persistance de l'article se fera par la DAO. En bouchonnant la DAO, nous ne nous occupons pas de l'implémentation de la DAO. Nous déléguons ceci à plus tard. Nous vérifions uniquement que nous faisons appel à la méthode d'enregistrement de l'article de la DAO avec en paramètre l'article à enregistrer. Nous écrions plus tard, toujours en mode TDD, le contrat de la méthode d'enregistrement de la DAO.

De même si nous avions eu à faire des calculs complexes. Nous aurions bouchonné la classe de calcul et nous aurions uniquement testé que nous avons effectivement fait appel à cette méthode de calcul.

Le test ne compile pas

Le code ne compile pas car l'implémentation n'existe pas.

Nous venons de terminer notre première étape dans le cycle du TDD.

TDD - Étape 2 : Définir l'implémentation

Nous passons à la deuxième étape : définir l'implémentation jusqu'à ce que le test passe.

Pour cela nous allons de nouveau nous servir du code écrit dans le test et des fonctionnalités de l'IDE pour créer l'implémentation manquante.

Nous avons ainsi de nouvelles propriétés dans la classe Article, une nouvelle interface ArticleDAO et pour le service ArticleService une nouvelle méthode ainsi que l'injection de la DAO.

Classe Article

public class Article {
 private String auteur;
 private String titre;
 private String contenu;
 private Date dateEnregistrement;
 ...getters / setters...
}

Interface de ArticleDAO

Nous avons uniquement besoin de l'interface pour la DAO pour ne pas nous soucier de l'implémentation.

public interface ArticleDAO {
 void save(Article article);
}

Interface du service ArticleService

public interface ArticleService {
 Article creerArticleVide();
 void saveArticle(Article article);
}

La classe du service ArticleServiceImpl

public class ArticleServiceImpl implements ArticleService {
 private ArticleDAO articleDAO;

 public Article creerArticleVide() {
   return new Article();
 }
 
 public void saveArticle(Article article) {
   article.setDateEnregistrement(new Date());
   articleDAO.save(article);
 }

 public void setArticleDAO(ArticleDAO articleDAO) {
   this.articleDAO = articleDAO;
 }
}

Le code compile, les tests sont maintenant en succès.

Atteindre la couverture à 100%

Cependant la couverture n'est pas à 100% car les méthodes "getXXX" des propriétés de la classe Article ne sont actuellement pas utilisées. Hors, les méthodes getters / setters sur les beans métiers sont obligatoires même si elles ne sont pas utilisées dans l'immédiat.

L'objectif de la couverture à 100% est de vérifier qu'aucun code n'est inutile. C'est pourquoi le test des méthodes getters / setters des beans métiers est un effort à faire pour atteindre la cible des 100%.

Pour cela, les trois lignes suivantes sont ajoutées à la fin du test :

 assertEquals("test auteur",article.getAuteur()); 
 assertEquals("test titre",article.getTitre()); 
 assertEquals("test contenu",article.getContenu());

Notre objectif est atteint : la couverture est maintenant à 100%.

Couverture du test

Couverture du projet

La couverture du projet est à 100% :

Nous pouvons passer à l'étape 3 du cycle du TDD.

TDD - Étape 3 : Réécrire le code pour simplifier et réorganiser

Le code étant déjà simple, nous n'avons pas besoin de réécrire le code.

Conclusion

Nous avons vu un exemple de mise en pratique du TDD.

Cette démarche change la façon de penser en se focalisant sur les règles fonctionnelles avant de réfléchir à comment les implémenter.

La pratique du TDD demande un temps d'adaptation, mais apporte de nombreux bénéfices.

Vous pouvez par exemple tester le TDD sur l'exemple de ce post pour vous entraîner.

Références

eclemma
Mockito - Documentation
Test Driven Design - Wikipedia Français - Wikipedia Anglais

TDD : Test Driven Development - Partie 1 - Principes

Ludovic Chaboud-Paupi — Tue, 30 Apr 2013 08:15:00 +0200

Le développement piloté par les tests ou TDD "Test Driven Development" nous impose de commencer par écrire les tests unitaires avant le code de la vraie classe d'implémentation.

Ce fonctionnement apporte de nombreux avantages, mais est difficile à appréhender car il change notre logique d'écriture du code.

Nous avons à écrire le contrat que doit réaliser la méthode testée AVANT d'écrire cette méthode. Ce contrat est écrit dans le test unitaire et impose le comportement d'une méthode en fonction de données de départ.

Ce post a pour objectif de vous présenter les principes du TDD ainsi que le cycle de développement en mode TDD. Un second post vous présentera une démonstration du TDD.

Règles du TDD

Le fonctionnement en mode TDD impose le respect des trois lois suivantes :

Première loi : Toujours écrire le test avant d'écrire le code de la méthode testée.

Vous ne devez pas écrire le code d'implémentation cible tant que vous n'avez pas écrit le code du test associé. C'est à dire qu'il est nécessaire d'avoir imposé le contrat avant d'écrire le code cible.

Deuxième loi : Définir dans le test les comportements et les résultat attendus de la méthode testée.

Le code de test impose le respect d'une règle métier. Ce test est en échec dans un premier temps : en effet, le code d'implémentation testé n'existe pas ou ne compile pas.

Troisième loi : Ecrire dans la méthode testée le code suffisant afin que le passage du test soit en succès.

Le code d'implémentation doit rester simple afin de gagner en efficacité. C'est pourquoi il est nécessaire de réécrire le code une fois que tous les tests sont en succès. De plus, les tests doivent rester en succès à la fin de la réécriture du code.

Quatrième loi : La couverture du code testé est à 100%.

La couverture du code à 100% permet d'éviter d'avoir du code non testé ou inutile qui peut être source d'erreurs.

Cycle du TDD

Le TDD repose sur les règles précédentes et permet d'avoir le cycle de développement suivant :

Ajout d'un nouveau test / Modification d'un test en cas de changement d'une règle existante
Ecrire le contenu de ce test pour imposer le comportement à la méthode d'implémentation testée
Lancer tous les tests et vérifier que seul ce test ne passe pas
Ecrire le code minimal dans la méthode testée pour réussir le test
Lancer tous les tests et vérifier qu'ils sont tous en succès
Vérifier que la couverture du code testé est à 100%
Réécrire le code d'implémentation testé pour le nettoyer et le simplifier
Lancer tous les tests et vérifier qu'ils sont tous en succès
Vérifier que la couverture du code testé est à 100%
Recommencer ce cycle pour ajouter ou modifier un test

Ce cycle est à effectuer à chaque changement dans le code de l'application.

L'intégration continue permet de valider que le code d'implémentation respecte toujours les contrats imposés par les tests.

Conditions du TDD

Le développement en mode TDD impose les conditions suivantes pour être efficace :

Couverture à 100%

La couverture du code testée doit toujours être de 100%. Ceci permet de ne pas avoir de code non testé ou inutile. Ceci est possible dans les classes non dépendantes d'un socle technique.

Dans eclipse, il est possible d'utiliser le plugin Eclemma pour vérifier la couverture du code à 100%.

Avoir des tests lisibles

Ce fonctionnement impose également de conserver du code de test propre, lisible et compréhensible en utilisant des noms de variable et une organisation compréhensibles.

Les tests unitaires deviennent la documentation fonctionnelle du code métier. C'est pourquoi le nom de la méthode de test doit être le plus explicite possible afin de savoir ce qu'elle teste sans même à avoir à lire le code. Il ne faut pas hésiter à avoir écrire le nom de la méthode sous forme de phrase ou avec le code de la règle métier testée.

Le test doit être unitaire

Les tests unitaires doivent s'exécuter le plus possible en dehors du contexte applicatif, c'est à dire sans avoir besoin de lancer le contexte Spring, d'avoir accès à la base de données ou à un serveur d'envoi de mails SMTP. Ainsi les tests pourront être lancés dans n'importe quel environnement.

Pour cela, le test doit rester unitaire, c'est à dire découplé du reste du contexte applicatif. Ainsi, dans le test, seule la classe testée est réellement instanciée, et toutes ses dépendances sont mockées. C'est à dire que les classes associées à la classe testée sont remplacées par des classes "mock" qui vont permettre de simuler le fonctionnement de leurs méthodes et de vérifier que ses méthodes sont bien appelées.

Le test doit s'exécuter rapidement

Le fait que le test est unitaire et découplé de l'environnement permet également de garantir que le test s'exécutera rapidement. En effet si l'exécution des tests est rapide, on aura plus tendance à lancer fréquemment l'intégralité des tests pour vérifier les non régressions.

D'autre part, les tests ne doivent par dépendre les uns des autres afin de pouvoir être lancés unitairement dans n'importe quel ordre. Ainsi un test ne doit pas dépendre du résultat d'un test précédent.

Le test doit échouer si une condition n'est pas remplie

Il est important qu'un test échoue dès qu'un comportement ou que le résultat n'est pas cohérent ou pas celui attendu. Ceci permet de détecter les anomalies le plus tôt possible. Ainsi il est nécessaire que le test unitaire remonte les exceptions au lieu de les gérer, de les mettre dans un fichier de log ou voir de les masquer. Ceci permet de les visualiser en cas d'échec.

Toujours écrire les tests avant le code

Il est important de toujours conserver l'ordre d'écriture : c'est à dire d'écrire les tests avant d'écrire le code d'implémentation.

Cet ordre permet de garder une dynamique dans le développement de l'application.

En effet, ceci garantit que le code d'implémentation sera toujours testable et ne sera pas trop complexe pour être testé. Cela évite également le découragement dans le cas où nous avons à écrire le test après avoir écrit notre méthode d'implémentation et que ce code est devenu trop complexe.

De plus, le fait d'imposer les contrats de la méthode testée rassure le développeur car le test garantit que le code développé fonctionne.

Bénéfices

Respect constant dans le temps des règles métiers

En écrivant les tests unitaires avant d'écrire le code de la méthode cible, cela nous oblige d'écrire chaque contrat dans ce test unitaire qui devient alors le garant du respect des règles métiers. Chaque méthode du test unitaire indique qu'une règle métier sera respectée par la méthode cible. Ainsi en cas de modification du code cible entraînant une échec du test, cela permet de détecter les régressions sans même avoir besoin de lancer l'application.

La plate-forme d'intégration continue permet cette détection à intervalle régulier et pour l'ensemble de l'équipe travaillant sur le projet. Le nommage de la méthode et de la classe de test doit être suffisamment lisible pour identifier la règle en échec sans même avoir besoin d'ouvrir la classe de test.

Simplification du code

D'autre part, le fait d'écrire le code minimal permettant de répondre au contrat décrit par le test permet la simplification du code.

Nous n'avons plus à effectuer de programmation défensive, ainsi pas besoin de tester le fait que tel argument de la méthode est null : les tests s'en chargent. Le seul cas où cela est nécessaire est s'il s'agit de méthodes de bibliothèques ou d'API publiques.

Nous n'avons plus tendance à ajouter de méthodes ou de classes utilitaires supplémentaires. Nous allons à l'essentiel, c'est à dire les éléments offerts par le langage Java et ses bibliothèques pour répondre aux besoins du test unitaire. Nous pourrons toujours réécrire le code plus tard, de toutes façons les tests sont là pour valider que le code répond toujours aux exigences.

Mise en confiance de l'équipe

Le fait que les tests garantissent le fonctionnement du code permet à une équipe d'être en confiance sur le travail réalisé par chacun.

Un membre de l'équipe pourra ainsi travailler sur le code d'un autre membre de l'équipe avec en garde fou les tests qui vont servir détecter les régressions. Ainsi cette personne sera davantage en confiance. Le fait que le test soit en erreur permet de dialoguer plus facilement entre les membres de l'équipe pour comprendre comment le code fonctionne réellement et ce qu'il est censé faire.

Amélioration technique

Les tests permettent de faciliter la réécriture et l'amélioration technique de l'application car ils permettent de lever des alertes si une modification a entraîné des régressions sur le fonctionnement interne de l'application.

Conclusion

Nous avons pu voir dans ce post les principes et le fonctionnement théorique du TDD qui apportent beaucoup de bénéfices notamment au niveau de la fiabilité et du respect des règles métiers.

Nous verrons dans un second post, une démonstration avec la mise en pratique des principes du TDD.

Trier efficacement les objets en Java - 2ème partie : Guava

Ludovic Chaboud-Paupi — Fri, 30 Nov 2012 19:14:00 +0100

Suite du billet précédent : "Trier efficacement les objets en Java - 1ère partie"

Le tri d'objets en Java s'effectue à l'aide de méthodes et de classes de comparaisons.

Cependant, l'écriture de ces méthodes peut vite devenir fastidieuse et être source d'erreurs lorsque les objets à comparer ont beaucoup de propriétés à tester.

Voyons comment la bibliothèque Guava de Google peut nous aider à simplifier l'écriture de ces méthodes.

Guava : Ordering et ComparisonChain

Nous verrons ainsi l'utilisation des classes Ordering et ComparisonChain de Guava.

La classe Ordering

La classe Ordering contient des méthodes qui permettent de définir plus simplement le tri d'une collection d'éléments. Elle contient également des méthodes qui permettent de lancer le tri d'une collection d'éléments.

Ordering implémente Comparator

Ordering implémente l'interface Comparator ce qui permet d'utiliser une instance Ordering de la même façon qu'une instance Comparator.

Définition d'une instance de Ordering

Nous pouvons définir une instance Ordering des deux manières suivantes :

Définition d'un Ordering à partir d'un Comparator existant

Nous pouvons définir un Ordering à partir d'un Comparator existant.

Ordering ordering = Ordering.from(comparator);

Ceci permet d'étendre le comportement de ce Comparator pour modifier le tri des éléments, comme par exemple inverser l'ordre du tri.

Définition d'un Ordering à l'aide d'une méthode de tri par défaut

Nous pouvons utiliser les ordres de tri fournis par la classe Ordering :

ordre naturel : la comparaison des instances repose sur la méthode compareTo de chaque instance. Ceci implique obligatoirement que les objets triés implémentent l'interface Comparable et la méthode compareTo.

 Ordering ordering = Ordering.natural();

utilisation de toString : la comparaison des instances repose sur la méthode toString de chaque instance.

 Ordering ordering = Ordering.usingToString();

tri selon les références des instances : la comparaison des instances repose sur la comparaison des références des instances.

 Ordering ordering = Ordering.arbitrary();

Etendre le comportement du tri

Ordering contient des méthodes qui permettent d'étendre le comportement de base de la comparaison.

Par exemple, nous pouvons inverser l'ordre du tri, gérer les instances non définies pour éviter les exceptions NullPointerException.

Inverser l'ordre

Pour inverser l'ordre, nous ajoutons l'appel à la méthode reverse :

Ordering ordering = Ordering.from(comparator).reverse();

Gérer le cas des objets non définis

Dans le cas où un des objets à comparer est nul, par défaut l'exception NullPointerException est levée.

Cependant ce cas peut être géré via l'appel à la méthode nullsFirst ou nullsLast qui indique que les instances non définies se retrouvent respectivement au début ou à la fin de la liste.

// Les instances nulles ne sont pas gérées et un __NullPointerException__ peut être levé
Ordering.from(comparator);

// Les instances nulles sont gérées et se retrouvent au début de la liste
Ordering.from(comparator).nullsFirst();

Si nous voulons les valeurs nulles à la fin, nous avons également l'expression suivante :

Ordering.natural().nullsLast();

Indiquer la propriété de l'objet sur laquelle effectuer le tri

La méthode onResultOf permet d'indiquer sur quelle propriété de l'objet effectuer le tri.

Cette méthode prend en paramètre une instance de Function qui est une autre classe fournit par la bibliothèque et qui permet de retourner une valeur à partir de l'objet passé en paramètre.

Par exemple, dans le cas d'un livre disposant de la propriété auteur, nous pouvons définir le tri sur l'ordre naturel selon cette propriété auteur :

final Ordering<Livre> livreOrdering =
    Ordering.natural().nullsFirst().onResultOf(new Function<Livre, String>() {
        public String apply(final Livre input)
        {
            return input.getAuteur();
        }
    });

final List<Livre> livresResultat = livreOrdering.sortedCopy(livres);

La méthode apply de la classe Function retourne ici la propriété auteur à partir de l'instance de Livre. L'auteur servira à trier les livres. De plus la méthode nullsFirst permet de gérer les cas où la collection contient des livres non définis.

Lancer le tri des éléments

Trier les éléments

Nous pouvons maintenant trier nos livres à l'aide notre nouveau comparateur, soit à l'aide Collections.sort, soit à l'aide de Ordering.sortedCopy.

// Livres à trier
List<Livre> livres = getLivres();

// Comparaison de livres
LivreComparator livreComparator = 
    Ordering.from(new LivreComparator()).nullFirst();

// Trier les livres
List<Livre> livreTries = 
    Ordering.from(livreComparator).sortedCopy(livres);

Exemples d'utilisation de la classe Ordering

Nous pouvons ainsi avoir les déclarations suivantes :

Tri naturel sur les auteurs d'un livre :

Nous trions les livres suivant un Comparator sur les livres en inversant l'ordre et gérant le cas des livres non définis :

final List<Livre> livresResultat =
            Ordering.from(livreComparator).reverse().nullsFirst().sortedCopy(livres);

Collection triée de livres

Nous définissons une collection triée de livres avec gestion des cas des instances nulles :

Set<Livre> livres = new TreeSet<Livre>(
            Ordering.from(livreComparator).nullFirst());

Conclusion sur l'utilisation d'un Ordering

La classe Ordering propose d'autres fonctionnalités non détaillées ici qui permettent d'étendre davantage le comportement

ComparisonChain

La classe ComparisonChain facilite l'écriture des méthodes de comparaison de type compareTo et des Comparator.

En effet, elle permet de tester à la suite chacune des propriétés des objets à comparer.

Elle s'utilise de la manière suivante :

on appelle dans un premier temps la méthode statique ComparisonChain.start()
on teste ensuite chaque propriété par une suite d'appels à la méthode ComparaisonChain.compare
enfin on récupère le résultat de la comparaison à l'aide de la méthode ComparaisonChain.result

Voici un exemple de l'utilisation de ComparisonChain dans le cas de la comparaison de deux livres :

public int compare(final Livre livre1,
                   final Livre livre2)
{
    return ComparisonChain
            .start()
            .compare(livre1.getAuteur(),
                     livre2.getAuteur())
            .compare(livre1.getAnnee(),
                     livre2.getAnnee())
            .compare(livre1.getTitre(),
                     livre2.getTitre())
            .result();
}

Nous voyons que la logique de comparaison est simplifiée.

Comparaison de propriétés spécifiques

De plus, la méthode compare peut prendre un troisième paramètre de type Comparator ou Ordering . Ceci permet d'indiquer un méthode de comparaison spécifique pour une propriété en indiquant un comparateur spécifique.

Ainsi, si nous souhaitons ne pas prendre en compte les accents dans la comparaison de chaînes de caractères, nous pouvons définir un comparateur de type Collator qui étend la classe Comparator.

Nous obtenons le code suivant :

public int compare(final Livre livre1,
                   final Livre livre2)
{
    // Comparator qui ne tient pas compte des accents
    final Collator collator = Collator.getInstance(Locale.FRENCH);
    collator.setStrength(Collator.PRIMARY);

    return ComparisonChain
            .start()
            .compare(livre1.getAuteur(),
                     livre2.getAuteur(),
                     Ordering.from(collator))
            .compare(livre1.getAnnee(),
                     livre2.getAnnee())
            .compare(livre1.getTitre(),
                     livre2.getTitre(),
                     Ordering.from(collator))
            .result();
}

Gérer les propriétés nulles pour éviter les NullPointerException

Attention : ComparisonChain ne gère pas les cas où une des instances à comparer est nulle. Pour éviter d'avoir des exceptions NullPointerException, nous devons gérer les cas des instances nulles de chaque propriété et des instances à comparer.

Pour cela, il est important d'utiliser la méthode Ordering.nullsFirst() que ce soit à la comparaison des propriétés ou lors du tri des éléments.

Ainsi, nous utilisons la classe Ordering pour étendre les comparateurs de la manière suivante :

// Comparateur
Comparator comparatorWithoutNullPointerException = 
    Ordering.from(comparator).nullFirst();

Ainsi dans le code ci-dessus, le cas où deux propriétés ne sont pas définies n'est pas géré.

L'expression suivante permet de gérer les valeurs nulles qui seront situées avant les valeurs non nulles :

// Gestion des instances nulles
Ordering.natural().nullsFirst();

Dans le cas où pour comparer les propriétés le Ordering repose sur un comparateur existant et que nous voulons gérer les cas où une des valeurs est nulles, nous aurons l'expression suivante :

Ordering.from(comparator).nullFirst();

Méthode de comparaison gérant les valeurs nulles

Dans notre exemple, nous avons un comparateur de type Collator au niveau de l'auteur et du titre, et pas de comparateur spécifique au niveau de l'année. Nous obtenons le code suivant pour gérer les valeurs nulles :

public int compare(final Livre livre1,
                   final Livre livre2)
{
     // Comparer sans tenir compte des accents et de la casse
     final Collator collator = Collator.getInstance(Locale.FRENCH);
     collator.setStrength(Collator.PRIMARY);

     // Comparaison sur les propriétés des livres
     return ComparisonChain
             .start() 
             .compare(livre1.getAuteur(),
                      livre2.getAuteur(),
                      Ordering.from(collator).nullsFirst())
             .compare(livre1.getAnnee(),
                      livre2.getAnnee(),
                      Ordering.natural().nullsFirst())
             .compare(livre1.getTitre(),
                      livre2.getTitre(),
                      Ordering.from(collator).nullsFirst())
             .result();
}

Lancer le tri à l'aide d'un ComparisonChain

Nous pouvons effectuer le tri à l'aide d'un ComparisonChain à l'aide de l'appel à la méthode Ordering.sortedCopy. Il faut également ne pas oublier d'utiliser la méthode Ordering.nullsFirst() pour gérer les cas des instances à comparer non défini et éviter ainsi les NullPointerException :

// Comparateur de livres
LivreComparator livreComparator = 
    Ordering.from(new LivreComparator()).nullFirst();

Exemple complet

Voici un exemple complet de tri de livres en utilisant ComparisonChain et Ordering .

Les livres sont triés suivant l'auteur, le titre puis l'année :

public class LivreComparator
	implements Comparator<Livre> 
{	
    // Comparaison de livres
    public int compare(final Livre livre1,
                       final Livre livre2)
    {
    	 // Comparer s'en tenir compte des accents et de la casse
    	final Collator collator = Collator.getInstance(Locale.FRENCH);
        collator.setStrength(Collator.PRIMARY);
        
        // Comparaison sur les propriétés des livres
        return ComparisonChain
                .start()
                .compare(livre1.getAuteur(),
                         livre2.getAuteur(),
                         Ordering.from(collator).nullsFirst())
                .compare(livre1.getAnnee(),
                         livre2.getAnnee(),
                         Ordering.natural().nullsFirst())
                .compare(livre1.getTitre(),
                         livre2.getTitre(),
                         Ordering.from(collator).nullsFirst())
                .result();
    }    
}

Nous trions les livres en utilisant ce comparateur :

LivreComparator livreComparator = new LivreComparator();

// Gérer le cas des livres non définis (éviter les NullPointerException)
Ordering<Livre> livreOrdering =
    Ordering.from(livreComparator).nullsFirst();

// Trier la liste des livres
List<Livre> livresResultat = livreOrdering.sortedCopy(livres);

Conclusion

L'utilisation des classes Ordering et ComparisonChain de Guava permettent de faciliter et de réduire les bugs en diminuant les cas complexes de comparaison des propriétés multiples des objets. Ceci permet de réduire les erreurs et de rendre plus fiable les méthodes de tri sur les éléments en utilisant les méthodes de comparaisons existantes, en chaînant les comparaisons des propriétés des objets et en gérant les cas des instances non définies.

Cependant, l'apprentissage de l'utilisation de ces classes demandent un peu de pratique mais qui ensuite apporte ces fruits en diminuant la complexité du code à écrire.

Référence

Billet précédent : "Trier efficacement les objets en Java - 1ère partie"

Voici quelques références sur les classes Ordering et ComparisonChain de la bibliothèque Guava :

Guava Wiki

Ordering : Documentation

Comparaison avec la méthode compareTo : compareTo

Comparaison avec la classe ComparisonChain : ComparisonChain

Trier efficacement les objets en Java - 1ère partie

Ludovic Chaboud-Paupi — Tue, 30 Oct 2012 12:00:00 +0100

Ce billet précède : "Trier efficacement les objets en Java - 2ème partie - Guava"

Le tri d'objets en Java est facilité par l'utilisation de méthodes de comparaison.

Nous allons voir dans cette première partie quel est le contrat de ces méthodes, comment les écrire et comment s'effectue le tri d'objets en Java à l'aide de ces méthodes.

Nous verrons ainsi l'utilité de l'interface Comparable et de la classe Comparator.

Comparaison d'objets

Les méthodes de comparaison permettent de trier une liste d'objets. Pour cela, ces méthodes consistent, pour deux instances d'un même objet, à comparer chacune de leurs propriétés et à indiquer quelle instance se situe avant l'autre selon l'ordre voulu.

Le contrat de ces méthodes de comparaison est défini par :

la méthode compareTo de l'interface Comparable
la méthode compare de la classe Comparator

Nous verrons que l'écriture de ces méthodes peuvent vite devenir fastidieuses et sources d'erreurs lorsque les objets à comparer ont beaucoup de propriétés à tester.

Nous prendrons comme exemple le tri d'une liste de livres.

Méthode compareTo de l'interface Comparable

L'objet lui-même étend l'interface Comparable. Cette interface implique l'écriture de la méthode de comparaison entre l'instance de l'objet et une autre instance de ce même objet.

int compareTo(T object);

Cette méthode compareTo retourne un nombre entier qui indique :

si < 0 : l'instance est avant la deuxième instance
si = 0 : les deux instances sont à la même position
si > 0 : l'instance est après la deuxième instance

Pour l'exemple des livres à trier, la classe Livre implémente Comparable et la méthode compareTo :

public class Livre
    implements Comparable<Livre>
{
    public int compareTo(Livre livre2) {
        (...)
    }
    (...)
}

Ainsi la méthode compareTo retourne un nombre entier qui indique :

si < 0, le livre est avant le livre 2
si = 0, le livre est à la même position que le livre 2
si > 0, le livre est après le livre 2

Méthode compare de la classe Comparator

La classe Comparator impose l'écriture de la méthode compare qui prend en paramètre les deux instances à comparer.

public class Comparator<T extends Object>
{
    int compare(T o1, T o2);
}

De même que pour la méthode compareTo de l'interface Comparable, la méthode compare retourne un nombre entier qui indique :

si < 0 : la première instance est avant la deuxième instance
si = 0 : les deux instances sont à la même position
si > 0 : la première instance est après la deuxième instance

Pour un livre, nous pouvons ainsi avoir le comparateur LivreComparator qui étend Comparator et qui implémente la méthode compare:

public class LivreComparator
    extends Comparator<Livre>
{
    public int compare(Livre livre1, Livre livre2) {
        (...)
    }
}

La méthode compare de la classe LivreComparator retourne un nombre entier qui indique :

si < 0 : le livre 1 est avant le livre 2
si = 0 : les deux livres sont à la même position
si > 0 : le livre 1 est après le livre 2

Trier une liste

A l'aide des méthodes de comparaison, nous pouvons trier une liste d'objets grâce à la méthode sort de java.util.Collections.

Via Comparable.compareTo

Dans le cas où on se base sur la méthode de comparaison compareTo via l'interface Comparable implémentée par l'objet, nous avons à appeler la méthode sort en indiquant uniquement la liste des objets.

// Liste des livres
List<Livre> livres = getLivres();

// Tri des livres selon la méthode compareTo de Livre
Collections.sort(livres);

via Comparator.compare

Dans le cas où on se base sur la méthode de comparaison compare du Comparator, nous avons à appeler la méthode sort en indiquant la liste des objets et le Comparator.

// liste des livres
List<Livre> livres = getLivres();

// Comparaison de livres
LivreComparator livreComparator = new LivreComparator();

// Tri des livres selon le Comparator
Collections.sort(livres, livreComparator);

Collections triées

Les collections TreeSet et TreeMap sont des collections dont les objets sont toujours triés selon une méthode de comparaison, soit via Comparable, soit à l'aide d'un Comparator.

Comparable

Ainsi si nous souhaitons une liste de livres sans doublon et toujours triés, nous pouvons nous baser sur l'interface Comparable de l'objet Livre. Pour cela, nous définissons une instance de TreeSet. Cette implémentation va détecter que l'objet ajouté à la collection implémente l'interface Comparable et se servira alors de la méthode compareTo pour trier les objets insérés dans la collection.

// Liste de livres triés selon la méthode compareTo de Livre
Set<Livre> livres = new TreeSet<Livre>();

Comparator

Pour le tri de la liste, nous pouvons également spécifier un Comparator externe.

// Comparaison de livres
LivreComparator livreComparator = new LivreComparator();

// Liste de livres triés selon le Comparator
Set<Livre> livres = new TreeSet<Livre>(livreComparator);

Ecriture des méthodes de comparaison

Comme déjà dit plus haut, les méthodes de comparaisons consiste à indiquer la position d'un élément par rapport à un autre élément en comparant chacune de leurs propriétés selon l'ordre voulu.

Par exemple, nous souhaitons trier une liste de livres. Chaque livre dispose d'un auteur, d'un titre et d'une année de publication.

Nous souhaitons trier ces livres dans l'ordre suivant : d'abord par auteur, puis par année de publication et enfin par titre.

En pratique, nous allons d'abord comparer l'auteur de deux livres. Si les deux auteurs sont différents, on indique quel livre se situe avant l'autre suivant l'auteur dans l'ordre alphabétique. Dans le cas où les deux auteurs sont identiques, nous continuons la comparaison sur l'année de publication. Si les deux années sont différentes, on indique quel livre se situe avant l'autre suivant l'année. Enfin, dans le cas où les deux années sont égales, on compare sur le titre, en indiquant le livre qui se situe avant l'autre suivant le titre et d'après l'ordre alphabétique. Dans le cas où les deux titres sont identiques, comme il n'y a plus d'autres propriétés à comparer, on indique que les deux livres sont à la même position dans la liste.

Ecriture de la méthode compareTo de l'interface Comparable

L'écriture de la méthode de comparaison compareTo de l'interface Comparable consiste à comparer les propriétés de l'instance de l'objet avec les propriétés d'une autre instance de même type d'objet.

int compareTo(T object);

Par exemple, nous prenons l'exemple de la classe Livre et nous voulons trier suivant l'auteur, puis l'année, puis le titre. Nous avons ainsi le code suivant :

public class Livre
    implements Comparable<Livre>
{
    
    public int compareTo(Livre livre2)
    {
        // Comparaison sur l'auteur
        int compAuteur = this.getAuteur().compareTo(livre2.getAuteur());
        if(compAuteur != 0) { return compAuteur; }

        // Comparaison sur l'année
        int compAnnee = this.getAnnee().compareTo(livre2.getAnnee());
        if(compAnnee != 0) { return compAnnee; }

        // Comparaison sur le titre
        int compTitre = this.getTitre().compareTo(livre2.getTitre());
        if(compTitre != 0) { return compTitre; }

        // Les deux livres sont à la même position
        return 0;
    }

    (...)
}

Nous avons ainsi comparer chaque propriété des deux instances. Dès qu'une des propriétés ne correspond pas entre les deux instances, on retourne le nombre entier indiquant l'ordre entre les deux instances.

Classe Comparator

L'écriture de la méthode compare qui prend en paramètre les deux instances à comparer consiste à comparer les propriétés de ces deux instances. Cette méthode est quasiment identique à la méthode compareTo de l'interface Comparable, hormis que l'on travaille sur deux instances d'objets qui ne sont pas liées au Comparator. Cette séparation permet de séparer la logique de comparaison de l'objet lui-même.

public class LivreComparator
    extends Comparator<Livre>
{
    
    public int compare(Livre livre1, Livre livre2)
    {
        // Comparaison sur l'auteur
        int compAuteur = livre1.getAuteur().compareTo(livre2.getAuteur());
        if(compAuteur != 0) { return compAuteur; }

        // Comparaison sur l'année
        int compAnnee = livre1.getAnnee().compareTo(livre2.getAnnee());
        if(compAnnee != 0) { return compAnnee; }

        // Comparaison sur le titre
        int compTitre = livre1.getTitre().compareTo(livre2.getTitre());
        if(compTitre != 0) { return compTitre; }

        // Les deux livres sont à la même position
        return 0;
    }

    (...)
}

Ainsi la méthode compare du Comparator ressemble à la méthode compareTo précédente.

Difficultés et pièges dans l'écriture des méthodes de comparaison

Ces méthodes de comparaison bien qu'utiles sont difficiles à écrire.

En effet, il est nécessaire de gérer plusieurs éléments:

la comparaison de deux propriétés change suivant le type de la propriété
il faut gérer le cas où un des deux objets ou une des propriétés n'est pas défini, pour ne pas avoir d'exception de type NullPointerException. Dans l'exemple, que se passe-t-il si l'auteur du livre 1 est non défini, c'est à dire null.

Voici par exemple, la méthode de comparaison avec la gestion des objets et des propriétés qui peuvent être non définis :

public class LivreComparator
    extends Comparator<Livre>
{
    
    public int compare(Livre livre1, Livre livre2)
    {
        if(livre1 == null) {
            if(livre2 == null) { 
                // Les deux livres ne sont pas définis
                return 0; 
            } else { 
                // Seul le livre 1 n'est pas défini
                return -1;
            }
        } else {
            // Seul le livre 2 n'est pas défini
            return 1;
        }

        // Comparaison sur l'auteur
        String auteurLivre1NonNull = 
            StringUtils.trimToEmpty(livre1.getAuteur());
        String auteurLivre2NonNull = 
            StringUtils.trimToEmpty(livre2.getAuteur());

        int compAuteur = 
            auteurLivre1NonNull.compareTo(auteurLivre2NonNull);
        if(compAuteur != 0) { return compAuteur; }

        // Comparaison sur l'année
        Integer anneeLivre1NonNull;
        if(livre1.getAnnee()==null) {
            anneeLivre1NonNull = 0;
        } else {
            anneeLivre1NonNull = livre1.getAnnee();
        }
        Integer anneeLivre2NonNull;
        if(livre2.getAnnee()==null) {
            anneeLivre2NonNull = 0;
        } else {
            anneeLivre2NonNull = livre2.getAnnee();
        }

        int compAnnee = 
            anneeLivre1NonNull.compareTo(anneeLivre2NonNull);
        if(compAnnee != 0) { return compAnnee; }

        // Comparaison sur le titre
        String titreLivre1NonNull = 
            StringUtils.trimToEmpty(livre1.getTitre());
        String titreLivre2NonNull = 
            StringUtils.trimToEmpty(livre2.getTitre());

        int compTitre = 
            titreLivre1NonNull.compareTo(titreLivre2NonNull);
        if(compTitre != 0) { return compTitre; }

        // Les deux livres sont à la même position
        return 0;
    }

    (...)
}

Conclusion

Il est important de maîtriser le tri des objets en Java avec l'utilisation de l'interface Comparable et de la classe Comparator.

Cependant, nous nous apercevons que l'écriture des méthodes de comparaison peut rapidement devenir un parcours du combattant où il faut déjouer tous les pièges.

L'écriture de tests unitaires peuvent aider, cependant le test de tous les cas possibles devient rapidement fastidieux.

C'est pourquoi je vous présenterai dans un second post des solutions pour faciliter l'écriture de ces méthodes de comparaison, notamment à l'aide de la bibliothèque Guava.

Référence

"Trier efficacement les objets en Java - 2ème partie - Guava"

Comparable : Javadoc
Comparator : Javadoc

Guava : Classer les éléments d'une collection

Ludovic Chaboud-Paupi — Thu, 25 Oct 2012 10:00:00 +0200

Pour certains algorithmes, nous avons besoin de classer des éléments selon une de leur propriété.

Nous allons voir dans un premier temps comment classer une liste d'objets de manière classique, puis nous verrons comment le faire plus simplement à l'aide des bibliothèques common-collections d'Apache et guava de Google.

Cas pratique

Nous prenons comme exemple la liste de livres d'une bibliothèque.

Nous souhaitons avoir le classement des ouvrages selon leur auteur de la manière suivante :

 - Auteur : Jules Vernes
    - Cinq semaines en ballon, 1863
    - Voyage au centre de la Terre, 1864
    - De la Terre à la Lune, 1865
 - Auteur : Rudyard Kipling
    - Le livre de la jungle, 1894
    - Le second livre de la jungle, 1895

Classer des objets

En Java, ce classement s'effectuerait de la manière suivante :

Nous avons la collection de type Map<clé, Collection<valeur>> qui permet de stocker pour chaque clé plusieurs valeurs.

Ainsi dans notre exemple, nous avons pour la clé auteur un ou plusieurs livres.

// Livres classés par auteur
Map<String, Collection<Livre>> livresParAuteurs =
    new HashMap<String, Collection<Livre>>();

Boucle de classement

La valorisation de ce tableau peut s'effectuer via le traitement suivant qui consiste à parcourir la liste des livres et pour chaque livre d'ajouter ce livre à la liste de ceux de l'auteur.

// Parcourt les livres
for (Livre livre : livres)
{
    // Auteur du livre
    String auteur = livre.getAuteur();

    // Liste des livres de l'auteur
    Collection<Livre> livresParAuteur = livresParAuteurs.get(auteur);

    // Créer la liste si elle n'existe pas
    if (livresParAuteur == null)
    {
        livresParAuteur = new ArrayList<Livre>();
        livresParAuteurs.put(auteur,
                             livresParAuteur);
    }

    // Ajoute le livre à la liste des livres de l'auteur
    livresParAuteur.add(livre);
}

Nous remarquons qu'une partie de ce code est redondant, il s'agit de créer la liste de livres dans le cas où elle n'existe pas déjà pour l'auteur.

Nous pouvons améliorer cela à l'aide du type Multimap.

Guava : MultiMap

L'interface Multimap<clé, valeur> correspond à la collection Map<clé, Collection<valeur>>.

Elle permet de gérer la création d'une nouvelle liste d'éléments pour tout nouvel ajout dans le tableau.

Il existe une implémentation de Multimap pour les bibliothèques common-collections d'Apache et guava de Google. Nous choisissons ici la bibliothèque guava de Google car elle supporte par défaut les types génériques.

Différence entre Multimap et Map

Cependant, il ne s'agit pas exactement de la collection Map<clé, Collection<valeur>>. En effet, comme expliqué sur le wiki de Guava, Multimap ne se comporte pas exactement comme la collection Map, notamment au niveau de la gestion de la liste d'éléments dans le cas où aucune valeur n'est présente pour une clé. Par exemple, Multimap retournera toujours une liste vide et jamais nulle dans le cas où aucun élément n'a été ajouté pour une clé du tableau.

Ceci est détaillé dans la documentation : Multimap is not a map

Multimap : Implémentations possibles

Les implémentations de Multimap<clé, valeur> correspondent à une implémentation possible Map<clé,Collection<valeur>>.

Les plus communes sont :

ArrayListMultimap<clé, valeur> => HashMap<clé, ArrayList<valeur>>
HashMultimap<clé, valeur> => HashMap<clé, HashSet<valeur>>
TreeMultimap<clé, valeur> => TreeMap<clé, TreeSet<valeur>>

Elles sont détaillées sur le wiki de Guava : Implémentations

Instanciation de Multimap

L'instanciation s'effectue via l'interface de la classe d'implémentation de la collection, ici ArrayListMultimap :

// Livres classés par auteur
final Multimap<String, Livre> livresParAuteurs = 
    ArrayListMultimap.create();

Ainsi le code précédent se simplifie car le code de création de la liste n'est plus utile :

for (final Livre livre : livres)
{
    // Auteur du livre
    final String auteur = livre.getAuteur();

    // Livres par auteur
    livresParAuteurs.put(auteur,
                         livre);
}

Cependant, hormis pour la récupération de l'auteur à partir de l'objet Livre, ce code n'a pas réellement de valeur ajoutée.

Nous pouvons de nouveau améliorer ce code pour ne plus avoir à parcourir nous-même, ni à gérer l'ajout des éléments dans le tableau.

Utilisation de Function

L'interface Function de guava correspond à une transformation d'un objet vers un autre objet.

Ainsi cette interface a deux types génériques, le type de l'objet initial et le type de l'objet qui sera en résultat de la fonction.

Function<initial, final>

L'interface impose l'implémentation de la méthode apply qui prend en paramètre l'objet à transformer et qui retourne le résultat de cette transformation.

public interface Function<F, T> {
    T apply(@Nullable F input);
}

Function

Dans notre exemple, nous allons utiliser cette interface Function pour définir une classe qui sera chargée de retourner l'auteur à partir de l'objet Livre :

Function<Livre, String> getAuteurFromLivreFunction = 
    new Function<Livre, String>() {
        public String apply(final Livre livre)
        {
            return livre.getAuteur();
        }
};

Multimaps.index

De plus, guava dispose de la méthode index via la classe Multimaps.

Cette méthode prend en paramètre la collection à traiter ainsi que la fonction qui va fournir la clé correspondant à chaque objet de la collection. Ceci permettra de définir pour une même clé tous les éléments associés de la collection.

Dans notre exemple, nous avons ainsi l'appel suivant :

final Multimap<String, Livre> livresParAuteurs =
    Multimaps.index(livres,
                    getAuteurFromLivreFunction);

Ceci permet de ne se focaliser que sur la gestion de la clé associée à chaque élément et non sur la façon dont le tableau est alimenté.

Conclusion

L'utilisation de la bibliothèque Guava de Google permet de simplifier l'écriture d'algorithmes basés sur des collections en Java.

Il est intéressant de lire la documentation de cette bibliothèque et de s'en inspirer pour améliorer nos pratiques et sur notre façon d'implémenter nos solutions.

L'interface Function tout comme Predicate permettent d'externaliser une partie du code spécifique et de les utiliser ainsi avec les méthodes de traitement génériques déjà implémentés dans Guava. Connaître ces méthodes permet de gagner du temps, réduit les risques d'erreurs et simplifie le code à écrire.

Références

Guava de Google

Site

https://code.google.com/p/guava-libraries/

Documentation

Dépendance Maven

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>13.0.1</version>
</dependency>

Predicate In Action

Ludovic Chaboud-Paupi — Sat, 20 Oct 2012 09:55:00 +0200

Habituellement, la recherche d'éléments dans une liste consiste à écrire une boucle de parcours d'éléments, un test pour savoir si l'élément parcouru est un de ceux que l'on cherche, puis à ajouter cet élément dans la liste de résultats. L'écriture de ce code est redondant, source d'erreurs et peut devenir complexe à lire et à maintenir.

Les prédicats permettent de simplifier l'écriture de méthodes de recherche d'éléments dans une liste.

En effet, l'interface Predicate permet d'externaliser la méthode de sélection des éléments recherchés.

Nous nous concentrons sur l'intention : que les éléments trouvés correspondent bien à ce que nous cherchons.

Ainsi, nous verrons une recherche classique de livres correspondant à certains critères. Ensuite nous verrons comment les bibliothèques common-collections d'Apache et guava de Google nous permettent de simplifier l'écriture de cette recherche à l'aide notamment de l'interface Predicate.

Exemple de recherche

Nous allons prendre comme exemple une bibliothèque qui dispose d'une liste de livre.

Pour chaque livre, nous disposons des informations suivantes : le titre, l'auteur et l'année de publication.

Nous recherchons les livres répondant aux critères suivant :

auteur : Rudyard Kipling
titre : le titre comporte les mots "jungle" et "grand"

Voyons comment nous pouvons effectuer cette recherche.

Recherche classique

Voici une boucle de recherche classique :

// Livres trouvés par la recherche
List<Livre> livreTrouves = new ArrayList<Livre>();

// Boucle de recherche
for(Livre livre : livres) {

    // Test des critères
    boolean estTrouve = 
        StringUtils.containsIgnoreCase(livre.getAuteur(),
                                       "Kipling")
     && StringUtils.containsIgnoreCase(livre.getTitre(),
                                       "livre")
     && StringUtils.containsIgnoreCase(livre.getTitre(),
                                       "jungle");

    // Le livre correspond aux critères
    if(estTrouve) {
        livreTrouves.add(livre);
    }
}

Amélioration de la recherche classique

Dans le code précédent, nous remarquons que nous avons une forte complexité au niveau du test sur les critères. En effet, la logique métier est concentrée dans ce test de vérification des critères.

C'est pourquoi nous créons une méthode spécifiquement chargée d'effectuer ce test.

Nous obtenons ainsi le code suivant :

/**
 * Vérifier si le livre correspond aux critères de recherche.
 * @param livre Livre
 * @return Indique si le livre correspond aux critères.
 */
private boolean verifierCritere(Livre livre)
{
    boolean estTrouve = 
        StringUtils.containsIgnoreCase(livre.getAuteur(),
                                       "Kipling")
     && StringUtils.containsIgnoreCase(livre.getTitre(),
                                       "livre")
     && StringUtils.containsIgnoreCase(livre.getTitre(),
                                       "jungle");

    return estTrouve;
}

La boucle de recherche est simplifiée :

// Livres trouvés par la recherche
List<Livre> livreTrouves = new ArrayList<Livre>();

// Boucle de recherche
for(Livre livre : livres) {

    // Le livre correspond aux critères
    if(verifierCritere(livre)) {
        livreTrouves.add(livre);
    }

}

Prédicat de recherche

La recherche a été simplifiée en externalisant dans une nouvelle méthode le test de vérification des critères sur un des éléments de la liste.

Les bibliothèques commons-collection et guava permettent d'effectuer cette séparation à l'aide de l'interface Predicate.

L'interface Predicate impose l'écriture d'une méthode prenant en paramètre un des éléments de la liste et qui se charge de retourner un booléen indiquant si l'élément correspond à ce que l'on cherche. Dans notre exemple, il s'agissait qu'un livre corresponde à un auteur et à un titre.

Cependant, la méthode principale conserve la logique de parcours des éléments de la liste et d'ajout des éléments trouvés dans la liste de résultats de la recherche. Les bibliothèques common-collections et guava permettent de ne plus avoir à écrire cette logique, tout simplement en fournissant à la méthode de recherche la liste des éléments et le prédicat.

Voyons deux exemples d'implémentation utilisant les deux bibliothèques.

Avec common-collections d'Apache

Nous utilisons l'interface Predicate :

public interface Predicate {
    boolean evaluate(Object object);
}

Voici l'implémentation de notre prédicat :

Predicate predicat = new Predicate() {
    public boolean evaluate(Object o) {
        Livre livre = (Livre) o;
        boolean estTrouve = 
            StringUtils.containsIgnoreCase(livre.getAuteur(),
                                           "Kipling")
         && StringUtils.containsIgnoreCase(livre.getTitre(),
                                           "livre")
         && StringUtils.containsIgnoreCase(livre.getTitre(),
                                           "jungle");

        return estTrouve;
    }
};

La méthode evaluate correspond à la méthode verifierCritere de notre code précédent.

La version officielle des commons-collection ne supporte pas les types génériques. Il existe cependant une version dérivée supportant les types génériques et qui sera indiquée à la fin de ce post.

Voici notre boucle de recherche qui utilise maintenant le prédicat :

// Livres trouvés par la recherche
List<Livre> livreTrouves = new ArrayList<Livre>();

// Boucle de recherche
for(Livre livre : livres) {
    // Test des critères
    if(predicat.evaluate(livre)) {
        // Le livre correspond aux critères
        livreTrouves.add(livre);
    }
}

Cette boucle de recherche peut être remplacée par l'appel de la méthode select de la classe CollectionUtils :

// Livres trouvés par la recherche
List<Livre> livreTrouves = new ArrayList<Livre>();

// Recherche de livres
CollectionUtils.select(livres,
                       predicate,
                       livreResultats);

Avec guava de Google

Même chose que précédemment, nous utilisons l'interface Predicate, mais cette fois-ci celle de guava :

public interface Predicate<T> {
    boolean apply(T input);
}

La bibliothèque guava supporte par défaut les types génériques ce qui simplifie l'écriture.

Voici l'implémentation de notre prédicat :

Predicate<Livre> predicate = new Predicate<Livre>() {
    public boolean apply(Livre livre)
        boolean estTrouve = 
            StringUtils.containsIgnoreCase(livre.getAuteur(),
                                           "Kipling")
         && StringUtils.containsIgnoreCase(livre.getTitre(),
                                           "livre")
         && StringUtils.containsIgnoreCase(livre.getTitre(),
                                           "jungle");

        return estTrouve;
    }
};

Voici notre boucle de recherche qui utilise maintenant le prédicat :

// Livres trouvés par la recherche
List<Livre> livreTrouves = new ArrayList<Livre>();

// Boucle de recherche
for(Livre livre : livres) {
    // Test des critères
    if(predicat.apply(livre)) {
        // Le livre correspond aux critères
        livreTrouves.add(livre);
    }
}

Cette boucle de recherche peut être remplacée par l'appel de la méthode filter de la classe Collections2 :

// Recherche de livres
Collection<Livre> livreResultats = 
    Collections2.filter(bibliotheque.getLivres(),
                         predicate);

Conclusion

L'utilisation des prédicats pour la recherche permet de se concentrer sur l'intention : vérifier que les éléments trouvés correspondent bien aux critères de recherche.

Références

Common-collections d'Apache

Site

http://commons.apache.org/collections/

Dépendance Maven

<dependency>
	<groupId>commons-collections</groupId>
	<artifactId>commons-collections</artifactId>
	<version>3.2.1</version>
</dependency>

Common-collections avec les types génériques

Site

https://github.com/megamattron/collections-generic

Dépendance Maven

<dependency>
    <groupId>net.sourceforge.collections</groupId>
    <artifactId>collections-generic</artifactId>
    <version>4.01</version>
</dependency>

Guava de Google

Site

Dépendance Maven

<dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>13.0.1</version>
</dependency>

Gestion des énumérations avec Struts

Ludovic Chaboud-Paupi — Sun, 30 Sep 2012 14:30:00 +0200

Struts en version 1 ne supporte pas, par défaut, les énumérations au niveau des valeurs postées depuis les formulaires HTML.

Je vous propose une solution pour que Struts puisse convertir directement la valeur qui a été sélectionnée dans le formulaire HTML vers la valeur de l'énumération correspondante.

Exemple d’énumération

Comme exemple, nous prenons l'énumération sur les statuts d’un dossier :

public enum DossierStatut {
  /** Statut : Brouillon. */
  BROUILLON("dossier.statut.brouillon"),
  /** Statut : Nouveau. */
  NOUVEAU("dossier.statut.nouveau"),
  /** Statut : En cours. */
  EN_COURS("dossier.statut.encours"),
  /** Statut : A valider. */
  A_VALIDER("dossier.statut.avalider"),
  /** Statut : Clos. */
  CLOS("dossier.statut.clos");
  
  /**
   * Clé de message du libellé du statut.
   */
  private final String libelle;
  
  /**
   * Constructeur.
   * @param libelle Libellé.
   */
  public DossierStatut(String libelle) {
    this.libelle = libelle;
  }

  /**
   * Retourne la clé de message du libellé.
   * @return Clé de message du libellé.
   */
  Public String getLibelle() {
    return this.libelle;
  }
}

Page de saisie d’une valeur énumérée

Nous prenons comme exemple une page de recherche de dossiers.

L’utilisateur peut saisir un ou plusieurs statuts de dossier à rechercher.

Cette page contient une liste de cases à cocher pour chacun des statuts.

Page JSP

<%@ page import="fr.netapsys.exemple.model.DossierStatut"%>

<form>

  <%-- Parcourt tous les statuts possibles du dossier --%>
  <c:forEach items="${rechercheForm.dossierStatuts}" 
             var="dossierStatut">

    <%-- Ne pas sélectionner par défaut --%>
    <c:set var="selected" value="" />
    <%-- Tester si cette valeur a été précédemment sélectionnée --%>
    <c:set var="selected">
      <c:forEach items="${rechercheForm.dossierStatutSelecteds}"
                 var="dossierStatutSelected">
        <c:if test="${dossierStatut eq dossierStatutSelected}">
          checked="checked"
        </c:if>
      </c:forEach>
    </c:set>

    <%-- Affichage de la case à cocher --%>
    <label>
      <input type="checkbox" 
             name="statuts" 
             value="${dossierStatut}"
             ${selected}
      />
      <bean message key="${dossierStatut.libelle}" />
    </label>

  </c:forEach>

</form>

La boucle « c:forEach » itère sur toutes les valeurs possibles de l'énumération DossierStatut. Ces valeurs ont été obtenues à l'aide de la méthode « getDossierStatuts » du formulaire Struts « rechercheForm ».

La variable « selected » permet d'indiquer si une des valeurs a été cochée précédemment. Pour cela, nous effectuons une recherche dans la liste des valeurs précédemment sélectionnées.

Formulaire Struts

La classe RechercheForm contient une propriété « dossierStatutSelecteds » dont le type est un tableau de valeurs de l'énumération « DossierStatut ». Cette propriété contient les valeurs sélectionnées dans la page par l'utilisateur.

La méthode « getAllDossierStatuts » retourne toutes les valeurs possibles de l'énumération de « DossierStatut ».

public RechercheForm extends ActionForm {
  /**
   * Statuts du dossier sélectionné.
   */
  private DossierStatut[] dossierStatutSelecteds;

  /**
   * {@inheritDoc}
   */
  public void reset(ActionMapping mapping,
                    HttpServletRequest request)
  {
    super.reset(mapping,
                request);
    // Réinitialiser les statuts de dossiers sélectionnés
    // à chaque soumission du formulaire de recherche
    this.dossierStatutSelecteds = null;
  }

  /**
   * Retourne les statuts de dossiers sélectionnés.
   * @return Statuts de dossiers sélectionnés.
  public DossierStatut[] getDossierStatutSelecteds() {
    return this.dossierStatutSelecteds;
  }

  /**
   * Définit les statuts de dossiers sélectionnés.
   * @param dossierStatuts Statuts de dossiers sélectionnés.
   */
  public void setDossierStatuts(DossierStatut[] dossierStatutSelecteds) {
    this.dossierStatutSelecteds = dossierStatutSelecteds;
  }

  /**
   * Retourne la liste de tous les statuts de dossier possibles.
   * @return Statuts de dossier possibles.
   */
  public List<DossierStatut> getAllDossierStatuts() {
    return DossierStatut.values();
  }
}

Déclarer le plugin de conversion des valeurs postées dans Struts

A l"aide d'une classe de conversion, nous indiquons à Struts comment effectuer la conversion entre une des valeurs de l’énumération et la chaîne de caractères String contenant le nom correspondant dans l’énumération.

Exemple : l’utilisateur a sélectionné « En cours », la valeur sélectionnée et postée par le formulaire HTML est la chaîne de caractères « EN_COURS ». Le converteur va convertir cette chaîne de caractères en la valeur de l’énumération « DossierStatut.EN_COURS ».

Plugin de conversion de données

Tout d'abord nous déclarons le plugin de conversion de données.

<struts-config>
(...)

  <!-- Conversion de données postées. -->
  <plug-in
    className="fr.netapsys.exemple.web.converter.plugin.ConverterPlugin"
  />

(...)
</struts-config>

La méthode « init » de la classe du plugin « ConverterPlugin » permet d’indiquer les énumérations et la classe de conversion des énumérations.

public class ConverterPlugin
    implements PlugIn
{
  /**
   * {@inheritDoc}
   */
  public void init(final ActionServlet servlet,
                   final ModuleConfig config)
  {
    final EnumConverter enumConverter = new EnumConverter();

    // Conversion de l’énumération DossierStatut
    ConvertUtils.register(enumConverter,
                          DossierStatut.class);

    // TODO Ajouter les autres énumérations à convertir
    // ConvertUtils.register(enumConverter,
    //                       MonEnumeration.class);

  }
}

Pour définir une nouvelle énumération à supporter, il suffit d'ajouter la ligne suivante de déclaration du Converter pour cette énumération :

  ConvertUtils.register(enumConverter,
                        MonEnumeration.class);

Classe de conversion

La classe de conversion est en charge de convertir la chaîne de caractères soumise par le formulaire HTML vers la valeur de l'énumération correspondante.

Cette classe permet également l'opération inverse de conversion de la valeur de l'énumération vers une chaîne de caractères.

La classe de conversion suivante est générique et peut s’utiliser pour n’importe quel type d’énumération.

import org.apache.commons.beanutils.Converter;
import org.apache.commons.lang.StringUtils;

public class EnumConverter
    implements Converter
{

  /**
   * {@inheritDoc}
   */
  @SuppressWarnings("unchecked")
  public Object convert(final Class type,
                        final Object value)
  {
        if (value == null)
        {
            return null;
        }

        // Conversion de String vers l’énumération.
        if (value instanceof String)
        {
            final String valueAsString = StringUtils.trimToNull((String) value);
            if (valueAsString == null)
            {
                return null;
            }
            else
      {
        // Recherche de la valeur de l'énumération.
        Class<Enum> enum = (Class<Enum>) type;
        for (final Enum enumeration : (enum.getEnumConstants())
        {
          if (StringUtils.equalsIgnoreCase(valueAsString,
                                           enumeration.name()))
          {
            return enumeration;
          }
        }
        return null;
      }
    }
    // Conversion de l’énumération vers String.
    else if (type.isInstance(value))
    {
      return ((Enum) value).name();
    }
    // Type non supporté.
    else
    {
      return value;
    }
  }
}

Conclusion

Vous pouvez maintenant utiliser directement les énumérations dans vos pages JSP avec Struts.

La classe de conversion des énumérations permet d’accélérer le développement et facilite la compréhension de ce qui a été développé pour du futures évolutions.

m2eclipse : Déclarez vos projets Maven dans Eclipse

Ludovic Chaboud-Paupi — Fri, 15 Jun 2012 13:00:00 +0200

m2eclipse édité par Sonatype permet le support de Maven dans l’IDE eclipse.

Ce plugin apporte des fonctionnalités notamment au niveau de l'édition des fichiers pom.xml, de la gestion et de l'actualisation des dépendances du projet dans Eclipse et de la gestion du filtrage des fichiers de ressources.

L’objectif de ce post est de vous présenter comment installer le plugin m2eclipse et comment configurer des projets existants ou créer de nouveaux projets.

Pré-requis

Pour que le plugin m2eclipse fonctionne, il est nécessaire d'avoir installé et configuré Maven en local.

Le fichier settings.xml doit exister dans le répertoire .m2 local.

Les variables d'environnement doivent être ajoutées :

 MAVEN_HOME : répertoire d'installation de maven
 M2_HOME : répertoire .m2 contenant le repository local de maven.

Installation du plugin

Nous installons m2eclipse via le marketplace d'Eclipse.

Pour cela, dans Eclipse, aller dans le menu Help > Eclipse marketplace.
Dans la nouvelle fenêtre Eclipse MarketPlace, saisir le mot maven dans Find et lancer la recherche.
Le plugin Maven Integration for Eclipse de Eclipse.org apparaît.

Cliquer sur le bouton Install et sélectionner les plugins suivants :
Maven Integration for Eclipse > m2e et m2e - slf4j

Cliquer sur le bouton Previous pour revenir sur l'écran de recherche du marketplace.

Rechercher cette fois-ci m2eclipse wtp.
Le plugin Maven Integration for Eclipse for WTP apparaît:

Cliquer sur le bouton Install et sélectionner le module Maven Integration for Eclipse for WTP > Maven Integration for WTP.

Confirmer l'installation et, à la fin de l'installation de m2eclipse, accepter le redémarrage d'eclipse.

Bravo ! m2eclipse est installé dans votre Eclipse :-)

Voyons comment configurer nos projets avec le plugin m2eclipse.

Configuration des projets avec m2eclipse

m2eclipse nous offre plusieurs possibilités : nous pouvons créer un nouveau projet Maven à partir de zéro, soit à partir d'un archétype Maven existant. Il est également possible d'importer un projet déjà existant dans notre workspace ou de le récupérer directement depuis le référentiel de sources en utilisant le composant SCM de Maven.

Cependant un projet doit obligatoirement disposer d'un fichier pom.xml pour être associé à m2eclipse.

Déclarer un projet existant en tant que projet Maven

Pour lier un projet existant au plugin m2eclipse, dans la vue Package Explorer cliquer sur le projet avec le bouton droit de la souris, puis sur Configure et Convert to Maven project.

Cependant, si le projet contient plusieurs modules Maven, aucun projet n'est pour le moment créé par le plugin m2eclipse. Il faut alors importer les projets comme indiqué dans le paragraphe suivant Importer des projets existants en tant que projets Maven.

Importer des projets existants en tant que projets Maven

L'importation de projets Maven permet d'importer tous les modules d'un projet Maven en tant que projet dans Eclipse.

Pour cela, dans Eclipse, aller dans le menu File puis Import.

La fenêtre de sélection du type d'importation apparaît. Sélectionner Maven > Existing Maven Projects.

La fenêtre d'importation propose alors d'indiquer le répertoire de base à partir duquel le plugin m2eclipse recherche les projets Maven à importer.

Par exemple, dans le cas d'un projet multi-modules, nous recherchons depuis la racine du projet les modules à importer dans Eclipse :

Après avoir cliqué sur le bouton Next, nous arrivons à la liste des utilitaires nécessaires au plugin m2eclipse à installer pour pouvoir exploiter les plugins de Maven. Par exemple, il aura besoin d'un connecteur pour utiliser le plugin maven-compiler-plugin pour effectuer la compilation du projet.

Après confirmation de l'importation, les projets détectés sont visibles dans le workspace d'Eclipse en tant que projets Maven.

Si le projet contient plusieurs modules Maven, un écran de sélection de ces modules apparaît pour sélectionner les projets à déclarer dans le workspace.

Récupérer le projet depuis le référentiel de sources SVN

Nous souhaitons récupérer notre projet directement depuis le référentiel de sources, par exemple SVN, et le référencer dans m2eclipse.

Pour cela, Saisir le raccourcir CTRL + N dans eclipse pour afficher la fenêtre New.
De nouvelles entrées apparaissent :

Sélectionner Maven > Checkout as Maven project from SCM.

La fenêtre Checkout as Maven project from SCM apparaît.

Sélection du référentiel de source

La liste déroulante à droite de SCM URL détermine le type de référentiel, par exemple SVN ou GIT.
Dans le cas où il n'est pas présent, il est nécessaire de l'installer via le lien Find more SCM connectors in the m2e MarketPlace.
La fenêtre m2e MarketPlace / Install m2e connectors apparaît et permet de rechercher le protocole souhaité.
Dans la liste de résultats, aller dans la section tout en bas m2e Team Providers et sélectionner le protocole souhaité.

Sélectionnons par exemple le connecteur m2e-subversive pour nous connecter au référentiel de sources SVN.
m2eclipse nous proposera alors d'installer Maven SCM Handler for Subversive.
Confirmer ce choix et accepter de redémarrer eclipse à la fin de l'installation.

Une fois Eclipse redémarré, utiliser le raccourci clavier CTRL + N pour afficher la fenêtre de création, puis rechercher Maven puis Checkout Maven Projects depuis SCM pour recommencer la récupération du projet depuis le référentiel de sources.

Cette fois-ci le référentiel SVN apparaît dans la liste déroulante du champ SCM.

Définir l'URL du projet dans le référentiel de sources

Le sélectionner et saisir l'URL complet du projet sur le référentiel SVN.

Ensuite, confirmer l'importation du projet depuis le référentiel.

Le plugin m2eclipse va importer le projet dans Eclipse en tant que projet Maven.
Il va également définir des projets dans Eclipse pour chacun des modules Maven.

Création d'un nouveau projet Maven

m2eclipse permet la création d'un nouveau projet Maven soit vide, soit à partir d'un archétype.

Création d'un nouveau projet vide

Dans Eclipse, utiliser le raccourci CTRL + N pour ouvrir la fenêtre de création.
Sélectionner Maven puis Maven Project.

La fenêtre New Maven Project apparaît, cocher Create a simple project (skip archetype selection) puis cliquer sur Next.

La fenêtre de configuration du projet apparaît :

Dans la zone Artifact, nous avons à définir les informations Maven de notre projet : Group Id, Artifact Id, Numéro de version, le type de packaging.

Attention : le packaging est important car il va déterminer le type et le contenu de notre nouveau projet.

Pour le packaging pom, le nouveau projet sera de type Projet simple. Il ne contiendra qu'un fichier pom.xml. Ce projet pourra être utilisé comme projet Maven parent et y définir des modules Maven.

Pour le packaging jar, le nouveau projet sera de type Projet Java. Il contiendra un fichier pom.xml et les répertoires de sources et de tests.

Pour le packaging war, le nouveau projet sera de type Projet Web et pourra être déployé avec le WTP de Eclipse. Il contiendra un fichier pom.xml, les répertoires de sources et tests ainsi qu'un répertoire src/main/webapp. Cependant le fichier web.xml sera à créer manuellement.

Nous pouvons également indiquer le projet parent. Le bouton Browse permet d'accéder à la fenêtre de recherche du projet parent. Cette recherche se base sur le paramétrage de l'actefactory dans les fichiers settings.xml de notre configuration Maven et référencés par le plugin m2eclipse.

Valider la création du projet : le projet apparaît dans le workspace d'Eclipse.

Création d'un nouveau projet depuis un archetype

Il est également possible de créer notre projet depuis un modèle de projet existant, aussi appelé archetype dans Maven.

Il existe plusieurs archetypes publics, comme appfuse. Ceci permet de partir d'un projet modèle pour tester de nouvelles technologies.

Pour créer notre projet depuis un archetype, dans Eclipse, utiliser le raccourci CTRL + N pour ouvrir la fenêtre de création. Sélectionner Maven puis Maven Projects.

La fenêtre New Maven Project apparaît.
Ne pas cocher Create a simple project (skip archetype selection) puis cliquer sur Next.

La fenêtre suivante permet de rechercher le projet Archetype qui va servir de modèle pour notre nouveau projet.
Nous pouvons rechercher par exemple appfuse qui propose des projets pour JSF, Spring MVC, Struts 2.
Sélectionner le projet modèle et cliquer sur Next.

Enfin la création de notre projet se termine par les propriétés Maven où nous définissons le Group Id, Artifact Id, la version et le package de base des classes Java de notre nouveau projet.

Après confirmation, notre nouveau projet apparaît dans le workspace en se basant sur le projet archetype comme modèle.

Conclusion

Maintenant que le plugin m2eclipse est installé et que votre projet est déclaré en tant que projet Maven, vous pouvez utiliser les fonctionnalités offertes par ce plugin, comme l'édition des fichiers pom.xml, la gestion des dépendances et la configuration automatique des projets dans Eclipse et avec le WTP.

SpringSource Tool Suite (STS) - Configuration des projets

Ludovic Chaboud-Paupi — Thu, 14 Jun 2012 18:09:00 +0200

Suite au post précédent où je vous présentais les fonctionnalités de SpringSource Tool Suite pour l'édition des fichiers XML de Spring, je vous présente ici comment effectuer la configuration de votre projet avec ce plugin.

Définir un projet Java comme étant un projet Spring

Maintenant, il est nécessaire de déclarer le projet en tant que projet de type Spring.

Ceci permet d'activer les fonctionnalités de SpringSource Tool Suite sur ce projet.

Un projet de type Spring est indiqué par le petit « S » comme Spring en haut à droite de l’icône du projet qui passe de à .

Voici deux méthodes: soit manuellement dans eclipse, soit via le plugin maven-eclipse-plugin de Maven.

Via Eclipse

Dans Eclipse > Vue Package Explorer ou Project Explorer > Cliquer avec le bouton droit de la souris sur le nom du projet > Spring Tools > Add Spring Project Nature.

Maintenant votre projet est déclaré comme étant de type « projet Spring ».

Via le plugin maven-eclipse de Maven

L’utilisation du plugin maven-eclipse-plugin de Maven permet de définir un projet Maven comme étant de type Spring dans eclipse.

La déclaration du projet Spring s’effectue en ajoutant des propriétés à la configuration du plugin maven-eclipse-plugin dans le fichier pom.xml du projet de cette façon :

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-eclipse-plugin</artifactId>
    (…)
    <configuration>
        <projectnatures>
            <projectnature>
                org.springframework.ide.eclipse.core.springnature
            </projectnature>
        </projectnatures>
        <additionalBuildcommands>
            <buildcommand>
                org.springframework.ide.eclipse.core.springbuilder
            </buildcommand>
        </additionalBuildcommands>
    </configuration>
</plugin>

Lancer la commande Maven pour mettre à jour la configuration des projets dans Eclipse :

mvn eclipse:clean eclipse:eclipse

Une fois réactualisé dans Eclipse, le projet sera indiqué comme étant un projet de type « Spring » : un petit « S » apparaîtra sur l'icône du projet dans eclipse :

Spring Project Builder

Le Spring Project Builder est ajouté dans la liste des Builders dans la configuration du projet.

Il indique que les fichiers de configurations de Spring seront analysés par SpringSource Tool Suite à chaque compilation du projet.

Ceci permet d’avoir à jour les références vers les beans Spring à chaque modification du code Java ou des fichiers XML de configuration Spring.

Configuration du projet avec SpringSource Tool Suite

Maintenant que notre projet est de type Spring, nous abordons la partie la plus importante de la configuration du projet.

Elle consiste à indiquer à SpringSource Tool Suite les fichiers Spring du projet actuel et des projets liés qui seront analysés par SpringSource Tool Suite au niveau de ce projet.

Nous avons ainsi deux listes à définir : une première liste pour indiquer les fichiers Spring du projet actuel et une seconde liste pour indiquer les fichiers Spring qui seront analysés par SpringSource Tool Suite.

Pour cela, dans la configuration Spring du projet, l’arborescence contient le nouvel élément Spring > Beans Support.

La partie droite Beans Support contient deux onglets Config Files et Config Sets.

Onglet Config Files

L’onglet Config Files permet de lister les fichiers XML de Spring du projet actuel. Les fichiers Spring peuvent être soit ajoutés soit manuellement, soit détectés automatiquement par « SpringSource Tool Suite » ce qui est fort pratique ! :-)

Une fois référencé, le fichier Spring est indiqué dans Eclipse avec un petit « S » sur son icône de fichier :

Onglet Config Sets

L’onglet Config Sets permet lui de d'indiquer les fichiers Spring qui sont réellement analysés par SpringSource Tool Suite pour le projet actuel.

Nous y indiquons ainsi les fichiers Spring du projet actuel et également les fichiers Spring des autres projets liés.

Important : pour les fichiers Spring des tests : il ne faut pas référencer les fichiers Spring des tests des autres projets liés, mais uniquement ceux des tests du projet actuel. En effet, les fichiers Spring de tests des autres projets ne sont pas utilisés dans le projet actuel et les référencer serait source d'erreurs.

Configuration d’un projet

Voyons comment configurer un projet.

Voici le projet bookstore à configurer. Il s'agit d'une application Web :

Liste des fichiers Spring

Dans un premier temps, nous définissons la liste des fichiers Spring du projet.

Dans la configuration du projet :

Beans Support > Onglet Config Files > Cliquer sur Scan > Ajouter tous les fichiers Spring détectés :

Groupe des fichiers Spring analysés par SpringSource Tool Suite

Dans un second temps, nous indiquons à SpringSource Tool Suite les fichiers Spring à prendre en compte pour ce projet.

Dans la configuration du projet :

Beans Support > Onglet Config Sets > Cliquer sur New > La fenêtre d'ajouts de fichiers Spring apparaît > Sélectionnez tous les fichiers Spring de bookstore-common.

Fin de la configuration

Voilà le projet est configuré, SpringSource Tool Suite connaît et analyse vos fichiers Spring à chaque compilation du projet.

SpringSource Tool Suite va pouvoir vous assister dans l'écriture de vos fichiers Spring et dans la détection des erreurs. Dans cette troisième partie, nous allons aborder la configuration d'un projet disposant de plusieurs modules liés entre eux.

En effet, ce type de configuration est moins évident que pour un projet simple.

L'objectif de ce post est de vous indiquer comment s'y prendre et d'éviter certains pièges.

Configuration d’un projet avec plusieurs modules

Pour comprendre comment configurer des projets disposant de plusieurs modules avec SpringSource Tool Suite, nous allons prendre l’exemple d'un projet disposant des deux modules suivants :

bookstore-common : module inclu sous forme de jar dans le module web
bookstore-web : module web

Nous avons donc une dépendance entre le projet common et le projet web car le module common est inclu sous forme de jar dans le module web.
Avec cette dépendance, les fichiers Spring du module common sont utilisés dans le module web. Ainsi les beans Spring du module web référencent les beans spring du module commun. Cette complication sera détaillée ci-dessous pour pouvoir configurer des projets multi-modules.

Voici l’organisation de ces deux modules :

Définir les fichiers Spring du projet « common »

Le module commun ne référence aucun fichier Spring d'un autre projet.

Il correspond au cas d'un projet simple : nous référençons dans SpringSource Tool Suite uniquement les fichiers Spring de ce projet.

Lister les fichiers Spring du projet « common »

Dans la configuration du projet :

Beans Support > Onglet Config Files > Cliquer sur Scan > Ajouter tous les fichiers Spring détectés :

Groupe des fichiers Spring analysés par SpringSource Tool Suite

Beans Support > Onglet Config Sets > Cliquer sur New > La fenêtre d'ajouts de fichiers Spring apparaît > Sélectionnez tous les fichiers Spring de bookstore-common.

Définir les fichiers Spring du projet « web »

Pour le projet bookstore-web, nous avons à référencer les fichiers Spring applicationContext-web.xml et applicationContext.xml et également les fichiers Spring de bookstore-common.

Lister les fichiers Spring du projet « web »

Dans la configuration du projet :

Beans Support > Onglet Config Files > Cliquer sur Scan > Ajouter tous les fichiers Spring détectés :

Groupe des fichiers Spring analysés par SpringSource Tool Suite

Beans Support > Onglet Config Sets > Cliquer sur New > La fenêtre d'ajouts de fichiers Spring apparaît > Sélectionnez les fichiers Spring de bookstore-web et de bookstore-common.

Important : les fichiers Spring des tests des autres projets ne doivent pas être sélectionnés.

Ici, le fichier Spring applicationContext-test.xml des tests du module commun ne doit pas être repris. Il est encadré ci-dessous en rouge. Ainsi son contenu n'impactera pas le module Web qui n'utilise pas ce fichier.

Conclusion

Au travers des exemples pour un projet simple et d'un projet multi-modules comportant des tests, vous avez pu voir comment effectuer la configuration sur votre projet.

Vous pourrez ainsi gagner du temps et de l'énergie dans l'écriture de vos fichiers XML Spring à l'aide de SpringSource Tool Suite.

Références :

SpringSource Tool Suite (STS) - Simplifiez-vous l'écriture des fichiers XML de Spring

Ludovic Chaboud-Paupi — Wed, 13 Jun 2012 12:12:00 +0200

SpringSource Tool Suite est un plugin qui permet le support de Spring dans Eclipse. Il se base sur le plugin Spring IDE.

Je vais vous présenter dans ce post les fonctionnalités de base de SpringSource Tool Suite qui sont de gérer la déclaration de beans Spring dans les fichiers XML.

Fonctionnalités de base de SpringSource Tool Suite

Rechercher un bean Spring

La recherche de beans Spring est simplifiée : nous pouvons rechercher la définition d'un bean Spring par son id de la même façon que si nous recherchions une classe Java.

La barre d’outils dans eclipse contient la nouvelle icône :

Cette icône donne accès à la fenêtre de recherche Open Bean permettant de rechercher un bean Spring par son id. Nous pouvons y utiliser des jokers « * ».

Le raccourci par défaut de recherche d’un bean Spring est ALT + SHIFT + B.

Auto-complétion

SpringSource Tool Suite nous assiste également dans l'édition des fichiers XML en apportant l'auto-complétion au niveau des noms des classes Java, des propriétés et des beans Spring référencés.

Auto-complétion du nom des classes Java

Nous déclarons la classe Java d'un bean Spring. SpringSource Tool Suite nous aide en affichant les classes Java possibles :

Auto-complétion du nom des propriétés

Nous ajoutons une nouvelle propriété, SpringSource Tool Suite liste toutes les propriétés possibles :

Auto-complétion des références vers d’autres beans Spring

SpringSource Tool Suite nous aide également lorsque nous définissons une référence vers un bean Spring en listant les noms possibles :

Navigation

SpringSource Tool Suite facilite la navigation dans les fichiers XML de Spring.
Il est ainsi possible de naviguer vers un bean Spring référencé ou vers la méthode « set » correspondant au nom de la propriété du bean Spring.

Navigation vers les beans référencés

SpringSource Tool Suite permet d'accéder à un bean Spring référencé en appuyant sur CTRL et en cliquant sur le nom du bean Spring :

CTRL + Clic sur le nom du bean Spring « bookDao » permet d’accéder à sa définition :

Navigation vers les méthodes « setters »

Il est également possible d'accéder depuis le nom de la propriété à la méthode « set » correspondante :

CTRL + Clic sur le nom de la propriété bookDao permet d’accéder à la méthode setBookDao de la classe. Ceci permet de voir comment est injectée la valeur de la propriété.

Gestion des erreurs

SpringSource Tool Suite indique les erreurs dans les fichiers de configuration de type :

la propriété ne peut pas être définie car la méthode « set » n'existe pas
le bean référencé n’existe pas
la classe d’implémentation n’existe pas
le bean à définir dans la propriété ne correspond pas au type de la propriété en question

Installation de SpringSource Tool Suite

SpringSource Tool Suite s’installe en tant que plugin via le Marketplace d'Eclipse.

Via le marketplace

Dans eclipse, aller dans le menu Help > Eclipse marketplace.
Dans la nouvelle fenêtre Eclipse MarketPlace, saisir les mots Spring Tool dans Find et lancer la recherche.

Le plugin SpringSource Tool Suite de SpringSource apparaît dans deux versions différentes. Il faut prendre la version qui correspond à la votre version d'Eclipse.

Cliquer sur le bouton Install et rendez-vous au chapitre Choix des modules du plugin pour finaliser l'installation.

Choix des modules du plugin

Pour l'installation de SpringSource Tool Suite, sélectionner les modules suivants :
Spring IDE > Spring IDE Core
SpringSource Tool Suite > SpringSource Tool Suite

Confirmer l'installation et, à la fin de l'installation de SpringSource Tool Suite, accepter le redémarrage d'Eclipse.

Fin de l'installation

Bravo ! SpringSource Tool Suite est installé dans votre Eclipse :-)

Conclusion

L’atout de SpringSource Tool Suite réside dans la recherche de beans Spring, l’auto-complétion et la détection d’erreurs dans la configuration qui n'apparaissent habituellement qu’au démarrage de l’application ou dans les tests unitaires.

SpringSource Tool Suite nous permet ainsi de gagner du temps et de faciliter l’écriture des fichiers XML de Spring.

Si vous souhaitez ajouter ces fonctionnalités sur votre projet dans Eclipse, rendez-vous dans le second post où je vous expliquerai comment configurer votre projet avec SpringSource Tool Suite.