|
Architecture J2EE - Comment organiser son application J2EE
3.Implémentation en J2EE
L’implémentation d’une
architecture complexe via J2EE est très modulable et très
spécifique. D’une application à une autre, les
outils et les technologies utilisés varient.
Nous allons étudier, ici, les
différents outils et technologies que l’on peut utiliser
pour chacune des couches d’une application J2EE.
3.1.Conception architecturale
La conception architecturale n’est
pas une mince affaire. Elle fait appel à de nombreux concepts,
souvent méconnus des débutants ou novices. Cette
conception se base sur les principes essentiels suivants
(d’autres existent également mais ne sont pas vus ici) :
- Faible Couplage
- Forte Cohésion
- Protection des variations
(interfaces, indirection, consultation de services …)
La granularité des composants
est très importante, en effet il s’agit de faible
couplage entre applications, sous-systèmes ou processus et non
entre petits objets. La granularité est définie par le
niveau de détails contenus dans une unité
d’information. Plus il y a de détails, plus bas est le
niveau de granularité ; à contrario, une forte
granularité est liée à un niveau faible de
détails.
Voici un exemple d’utilisation
de la granularité au sein d’un programme :
//
forte granularité
public
void methodForteGranularite(int id, String name, String email …);
//
faible granularité
Public
void methodFaibleGranularite(PeopleVo people);
Ceci est un exemple au niveau des paramètres de méthodes,
cependant la granularité peut s’évaluer sur des
parties de programmes (combien d’entités avez-vous ?)
ou au niveau global du programme (combien de modules avez-vous ?)…
3.1.1.Faible Couplage
Le couplage est une mesure de degré
auquel un élément est lié à un autre, en
a connaissance ou en dépend. S’il y a couplage ou
dépendance, l’objet dépendant peut être
affecté par les modifications de celui dont il dépend.
Evidemment une sous-classe est fortement dépendante à
sa super-classe. Un objet A faisant appel aux méthodes d’un
objet B a un couplage aux services de B.
Le problème est : Comment
réduire l’impact des modifications ?
La solution est : Affecter les
responsabilités de sorte à éviter tout couplage
inutile.
En résumé, le faible
couplage permet de séparer au maximum l’implémentation
de l’aspect fonctionnel afin d’avoir à effectuer
que très peu de modifications (voir aucune) lors d’un
changement de l’implémentation.
Un exemple très courant est
celui des « drivers » ou pilotes. Le système
principale définit une structure commune à tous les
pilotes (ou à un type de pilote) ; chaque pilote se doit
d’implémenter l’ensemble de la structure afin
d’être utilisé par le système. Dans ce cas
là, le système n’a pas connaissance de
l’implémentation (cas également des API …)
En image : (ce qu’il ne
faut pas faire !!!)
3.1.2.Forte Cohésion
L’un des problèmes du
« débutant » est qu’il ne sait pas
exactement où effectuer les traitements et finit très
souvent par aboutir à des classes comportant des milliers de
lignes (ingérables et pu évolutives). Tout comme un bon
chef de projet, votre application se doit se bien savoir déléguer
les tâches à effectuer.
Cependant, une mauvaise cohésion
(faible cohésion) n’implique pas qu’un objet
exécute tout le travail seul : un objet faiblement
cohésif de deux mille lignes de code collabore certainement
avec beaucoup d’autres objets ! Le point essentiel est que
toutes ses interactions tendent également à créer
un mauvais couplage (fort). Il faut donc bien penser la liaison entre
vos objets (ce qui n’est pas toujours évident).
Préférez toujours une
solution qui présente le plus de cohésion.
Le problème est : Comment
s’assurer que les objets restent compréhensibles et
faciles à gérer, et, contribuent au Faible Couplage ?
La solution est : Affecter les
responsabilités pour que la cohésion demeure élevée.
3.1.3.Protection des variations
La protection des variations est le
concept générique. Il permet d’identifier les
points de variations ou d’instabilité prévisibles.
Mais également d’affecter les responsabilités
pour créer une interface stable autour d’eux.
Certaines modifications du système
sont prévisibles. Le pattern protection des variations permet
de protéger la structure et les classes contre une variation
entraînant un effort très important. Le principe le plus
connu est le mécanisme d’abstraction qui permet de créer
une interface stable autour des objets du système.
Si vous interdisez l’accès
direct des clients aux attributs alors le système est protégé
contre des changements de traitement à l’intérieur
des classes (exemple d’utilisation des getters / setters). Un
très bon exemple d’utilisation de ce pattern est
l’utilisation de machine virtuelle qui permet de protéger
des variations de la plateforme.
La protection des variations est donc
à mettre au dessus des autres patterns, car c’est un
concept (pouvant être mis en place avec plusieurs solutions).
|
|
 |
