Blog de Baptiste Wicht

Un article de Baptiste Wicht    2 Commentaires

Après avoir décrit dans le premier billet en quoi consistait une application modulaire et ce qu’était un module, nous allons maintenant nous pencher plus spécialement sur les modules.

Nous avons dit qu’un module permettait de rajouter des fonctionnalités à l’application principale. Mais avant de se lancer dans le moindre code, il va falloir définir exactement ce que seront nos modules, ce qu’ils pourront faire, s’il y aura plusieurs types de modules, …

C’est ce que nous allons voir dans ce billet.

La première question à se poser est : « Que vont pouvoir faire mes modules ? ». C’est-à-dire, qu’est-ce qu’un module pourra ajouter à l’application principale.

Nous avons dit qu’un module rajoutait des fonctionnalités à l’application principale, mais il faut maintenant spécifier ce que les modules pourront ajouter et la manière dont ils vont pouvoir les ajouter. En plus d’ajouter, un module pourra éventuellement modifier l’application principale.

Ce que les modules pourront faire va dépendre également du type d’application modulaire :

• Dans le cas du premier type (application normale avec possibilité d’extension par module), le module va rajouter des fonctionnalités de types spécifiques, c’est-à-dire en accord avec l’application. Prenons le cas d’une application qui permet de regarder la télévision via internet. Dans ce cas-là, les modules pourront par exemple rajouter une chaîne à l’application ou rajouter un format de conversion vidéo pour l’enregistrement. Il peut aussi rajouter une fonctionnalité complète comme des statistiques qui indiqueraient le nombre d’heures pendant lesquelles on a regardé la télé sur ce programme et la chaîne la plus regardée.
• Dans le cas du second type (application vide de base et modules qui rendent l’application utilisable), les modules ne vont pas rajouter des fonctionnalités à l’application principale étant donné qu’elle ne permet rien, mais vont définir ce que va faire l’application. Cette fois, les modules, c’est l’application. Prenons mon application (JTheque) qui est destiné à gérer des collections diverses. J’ai pour le moment un module Films et un module Livres. J’ai ensuite des plus petits modules comme le modules Stats ou un module qui permet de gérer une liste de films à acheter. On voit qu’on a déja des modules beaucoup plus large. En plus, avec quelque chose de ce type, on pourrait imaginer une module qui ferait quelque chose de complètement différent de l’application de base, comme un module Calculette qui ajouterait une calculatrice à l’application, ce qui n’est pas du tout le but de l’application de base mais qui est rendue possible par les possibilités d’extension du coeur de l’application.

Dans ces deux cas, il faut donc définir certains points d’extension. Dans le cas de JTheque, voici les points d’extension que j’ai créé pour mes modules :

• Rajouter des onglets dans la vue principale
• Rajouter des composants dans la barre d’état
• Rajouter des éléments dans le menu de la vue principale
• Rajouter des onglets dans la vue de configuration

A partir de ces points d’extension, les modules peuvent faire beaucoup de choses. Par exemple, si on veut faire une calculette, on peut imaginer rajouter un onglet principal avec une calculette, ou alors faire une fenêtre dediée et rajouter un élément dans le menu qui ouvrirait cette fenêtre.

Ceci est donc laissé au libre choix du développeur, mais il faut y penser avant et bien réfléchir à ce que ça implique.

En plus de points d’extension, le coeur de l’application fournit aussi une série de services aux modules. Ces services peuvent être de simples classes utilitaires ou alors un gestionnaire de persistence d’entités, un gestionnaire de log ou encore un gestionnaire permettant aux modules d’enregistrer des informations pour les retrouver après l’arrêt de l’application.

Là encore ces points sont laissés à la discrétion du développeur. Ces services ne sont pas obligatoires, mais cela permet d’éviter que chaque module doivent tout refaire. En plus, cela permet également une standardisation. En effet, les modules vont (normalement) utiliser le même type de persistence, le même type de log, … Ce qui est plus facile à gérer ensuite. Bien entendu, rien n’empêche un module d’utiliser son propre système de log si celui du coeur ne lui convient pas.

Pour la petite histoire, voilà les services que j’offre à mes modules :

• Gestionnaire de logs : Permet aux modules d’obtenir des loggers (Log4J) pour logger différentes actions.
• Gestionnaire d’erreurs : Permet aux modules d’afficher des erreurs facilement
• Gestionnaire de vue : Permet aux modules d’afficher des messages, de demander quelque chose à l’utilisateur, …
• Gestionnaire de beans : Permet aux modules d’utiliser de l’IOC (Spring).
• Gestionnaire de ressources : Permet aux modules de bénéficier de l’internationalisation (Spring) ainsi que d’un cache d’image
• Gestionnaire de persistence : Permet aux modules de gérer des entités persistentes (JPA/Hibernate).
• Gestionnaire d’états : Permet aux modules de stocker des états.

On peut aussi réfléchir si on veut un seul type de module ou s’il y en aura plusieurs. Dans mon cas, j’ai fait une petite distinction entre des modules dits principaux et des modules dits secondaires. Les fonctionnalités sont exactement les mêmes sauf qu’un seul module principal peut être lancé en même temps. Par exemple, le module films est un module principal et le module ajoutant une liste de films à acheter est un module secondaire.

Le dernier point que je vois à traiter au niveau des modules est la dépendance entre modules. On peut permettre ou non qu’un module dépende d’un autre module. Cela ajoute un niveau de difficulté supplémentaire au niveau de l’implémentation étant donné qu’il faudra vérifier que la dépendance est remplie avant de pouvoir lancer le module. Cela implique également que le module principal doit être lancé avant le module qui en dépent. Et que faire des dépendances circulaires ? Bref, cela est également laissé au choix du développeur qui peut permettre les dépendances intra-modules ou non. Dans mon cas, je l’ai permis, j’ai par exemple, le module Stats qui dépend du module Films étant donné qu’il a besoin des informations sur les films, acteurs et réalisateurs pour générer ses statistiques.

Voilà, j’en ai fini (enfin, me direz-vous ^^) avec les caractéristiques des modules. Comme pour le premier article, n’hésitez surtout pas à vous manifester si vous avez des questions ou si vous n’êtes pas d’accord avec quelque chose que j’ai dit ou si vous aimeriez plus d’informations sur un point spécifique