Pseudo-Archive Java : Accueil -|- Visuel -|- Logistique -|- Applications réparties	La pseudo-archive Java est un service proposé par la SARL diaam informatique, et il est hébergé par la Sogid.

Date sent:      	Mon, 17 Sep 2001 09:51:25 +0200
From:           	Sebastien Cesbron <scesbron@ifrance.com>
To:             	java@u-strasbg.fr
Subject:        	Décomposition en packages
Send reply to:  	java@u-strasbg.fr

Salut,

Je me suis rendu compte que dans mon application j'ai un cycle dans mon
graphe des packages : horreur ;-) J'ai envie de supprimer ce graphe mais
je me suis rendu compte que j'avais beaucoup de mal à décomposer mon appli
en packages sensés. Je me demandais si quelqu'un avait connaissance d'un
article présentant une technique ou des best-practices pour la
décomposition en packages

Merci

Seb

__________________________________________________________________________
____ ifrance.com, l'email gratuit le plus complet de l'Internet ! vos
emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
http://www.ifrance.com/_reloc/email.emailif

From:           	"Arnaud Hallais" <arnaud.hallais@atosorigin.com>
To:             	<java@u-strasbg.fr>
Subject:        	Re: Décomposition en packages
Date sent:      	Mon, 17 Sep 2001 10:15:39 +0200
Send reply to:  	java@u-strasbg.fr

> Je me suis rendu compte que dans mon application j'ai un cycle dans mon
> graphe des packages : horreur ;-)

pourquoi serait-ce une horreur? toutes mes applis ont des cycles dans le
graphe des packages! comment faire autrement....

class gui.X a un membre core.Y
et
class core.Y a un membre gui.X

relation 1-1 de base en object. Pour enlever le cycle, il faut mettre X et
Y dans le meme package. Moi pas vouloir, mon appli marche sans interface
graphique. le package gui c'est de la fioriture, de l'optionnel... sinon
j'ai pas de "best practice" sous la main

a++

----- Original Message -----
From: "Sebastien Cesbron" <scesbron@ifrance.com>
To: <java@u-strasbg.fr>
Sent: Monday, September 17, 2001 9:51 AM
Subject: Décomposition en packages


> Salut,
>
> Je me suis rendu compte que dans mon application j'ai un cycle dans mon
> graphe des packages : horreur ;-) J'ai envie de supprimer ce graphe mais
> je me suis rendu compte que j'avais beaucoup de mal à décomposer mon
> appli en packages sensés. Je me demandais si quelqu'un avait
> connaissance d'un article présentant une technique ou des best-practices
> pour la décomposition en packages
>
> Merci
>
> Seb
>
>
__________________________________________________________________________
__ __ > ifrance.com, l'email gratuit le plus complet de l'Internet ! > vos
emails depuis un navigateur, en POP3, sur Minitel, sur le WAP... >
http://www.ifrance.com/_reloc/email.emailif

Date sent:      	Mon, 17 Sep 2001 10:35:26 +0200
From:           	Sebastien Cesbron <scesbron@ifrance.com>
To:             	java@u-strasbg.fr
Subject:        	Re: Décomposition en packages
Send reply to:  	java@u-strasbg.fr

Prends n'importe quel AGL (par exemple Objecteering) et tu ne pourras par
créer d'application avec un graphe de package cyclique. Si deux packages
sont inter-dépendants, ils doivent évoluer ensemble et donc il n'y a pas
forcément d'intérêt à avoir deux packages distincts. Il y avait un article
de feu "Developpeur Référence" qui expliquait bien ceci, c'est le principe
des dépendances acycliques, d'ailleurs en cherchant "Acyclic Dependencies
Principle" sur google on peut trouver des explications sur le pourquoi du
comment.

Souvent, on peut rompre un graphe cyclique à l'aide de l'héritage ou de
l'implémentation d'une interface. En effet au lieu d'avoir : A <--> B on a
A -- utilise --> I_B(interface) <-- hérite -- B -- utilise --> I_A
(interface) <-- hérite -- A (cf diag UML joint) et du coup il n'y a plus
de cycle puisque A et B connaissent C mais ne se connaissent pas entre
eux. Cela permet de faire évoluer l'implémentation (B) sans impact sur
l'utilisateur (A) du moment que l'interface (I_A) reste inchangée.

Je suis donc à la recherche d'un article qui pousserait la réfléxion que
je viens d'exposer un peu plus loin et qui donnerait quelques conseils
pour créer des packages qui ne posent pas trop de problème lors de
l'évolution d'une application

A+

Seb

Arnaud Hallais wrote:
> 
> > Je me suis rendu compte que dans mon application j'ai un cycle dans
> > mon graphe des packages : horreur ;-)
> 
> pourquoi serait-ce une horreur? toutes mes applis ont des cycles dans le
> graphe des packages! comment faire autrement....
> 
> class gui.X a un membre core.Y
> et
> class core.Y a un membre gui.X
> 
> relation 1-1 de base en object. Pour enlever le cycle, il faut mettre X
> et Y dans le meme package. Moi pas vouloir, mon appli marche sans
> interface graphique. le package gui c'est de la fioriture, de
> l'optionnel... sinon j'ai pas de "best practice" sous la main
> 
> a++
> 
> ----- Original Message -----
> From: "Sebastien Cesbron" <scesbron@ifrance.com>
> To: <java@u-strasbg.fr>
> Sent: Monday, September 17, 2001 9:51 AM
> Subject: Décomposition en packages
> 
> > Salut,
> >
> > Je me suis rendu compte que dans mon application j'ai un cycle dans
> > mon graphe des packages : horreur ;-) J'ai envie de supprimer ce
> > graphe mais je me suis rendu compte que j'avais beaucoup de mal à
> > décomposer mon appli en packages sensés. Je me demandais si quelqu'un
> > avait connaissance d'un article présentant une technique ou des
> > best-practices pour la décomposition en packages
> >
> > Merci
> >
> > Seb
> >
> >
> ________________________________________________________________________
> ____ __
> > ifrance.com, l'email gratuit le plus complet de l'Internet !
> > vos emails depuis un navigateur, en POP3, sur Minitel, sur le WAP...
> > http://www.ifrance.com/_reloc/email.emailif

Date sent:      	Mon, 17 Sep 2001 10:59:18 +0200
From:           	Jerome Moliere <moliere@viveo-montpellier.com>
To:             	java@u-strasbg.fr
Subject:        	Re: Décomposition en packages
Send reply to:  	java@u-strasbg.fr

>
>
>
>Je suis donc à la recherche d'un article qui pousserait la réfléxion que
>je viens d'exposer un peu plus loin et qui donnerait quelques conseils
>pour créer des packages qui ne posent pas trop de problème lors de
>l'évolution d'une application
>

en fait je pense qu'il faut que tu lises le principe de liskov, le DIP
etc...

http://www.design-up.com/design/principesoo/liste.html
bonne lecture (ce site est un must absolu avec les liens vers les 
articles originaux)


Jerome

>
>
>
>
>

From:           	"Cedric Beust" <cedric@beust.com>
To:             	"Java Mailing-list" <java@u-strasbg.fr>
Subject:        	Re: Decomposition en packages
Date sent:      	Mon, 17 Sep 2001 08:26:28 -0700
Send reply to:  	java@u-strasbg.fr

> From: Arnaud Hallais [mailto:arnaud.hallais@atosorigin.com]

> pourquoi serait-ce une horreur? toutes mes applis ont des cycles dans le
> graphe des packages! comment faire autrement....
> 
> class gui.X a un membre core.Y
> et
> class core.Y a un membre gui.X
> 
> relation 1-1 de base en object. Pour enlever le cycle, il faut mettre X
> et Y dans le meme package.

Non, il suffit de

1) Ne pas referencer des membres mais des methodes
2) Creer une interface ICore dans un package partage' par les deux classes

Il est toujours possible de transformer un graphe de dependances en arbre.

-- 
Cedric

Date sent:      	Mon, 17 Sep 2001 19:50:39 +0200
From:           	Jerome Moliere <moliere@viveo-montpellier.com>
To:             	java@u-strasbg.fr
Subject:        	Re: Decomposition en packages
Send reply to:  	java@u-strasbg.fr



>
>2) Creer une interface ICore dans un package partage' par les deux
>classes
>
>Il est toujours possible de transformer un graphe de dependances en
>arbre.
>
exact, cf le DIP on peut enfin casser la dependance naturelle de nos
precieuses classes metiers que l'on souhaite reutilisable avec les
vilaines classes techniques jetables... si l'on prend soin de creer une
interface dans le package business implementee dans les classes techniques
et là le couplage est ce qu'il doit etre : les classes metiers ne
dependent plus de classes hautement fragiles
 puisque dependant d'une BDD ou d'un FS...

Jerome

From:           	"Herve AGNOUX" <hagnoux@mail.club-internet.fr>
To:             	java@u-strasbg.fr
Date sent:      	Tue, 18 Sep 2001 09:32:03 +0200
Subject:        	Re: Décomposition en packages
Priority:       	normal
Send reply to:  	java@u-strasbg.fr

Le 17 Sep 01, Sebastien Cesbron a écrit :

> [...]
> en packages sensés. Je me demandais si quelqu'un avait connaissance d'un
> article présentant une technique ou des best-practices pour la
> décomposition en packages
> 

Bon, j'explique mes petites combines. J'ai pas encore trouvé de 
règles sémantiques, comme l'on dit, juste des règles d'écriture.

Pour les règles sémantiques, j'aime bien le truc du JNDI, d'appeller le
package "naming", qui représente la démarche, non l'objet. Manque de bol,
j'ai jamais réussi à l'appliquer pour mes développements, et, pire que
tout, chaque fois que je veux utiliser le package, je l'appelle "jndi" au
lieu de "naming"...

Les règles d'écriture sont un peu idiotes, comme toutes les règles 
d'écriture :

1) Une classe peu utiliser les classes de son paquage et de ses 
sous paquages.

2) Une classe A peut utiliser une classe B d'une autre branche, si, 
pour l'utiliser, il suffit d'importer des classes de ce package, ou des
classes de packages des pères de B.

3) Si 2) n'est pas respecté, on peut encore utiliser une classe 
d'une autre branche si celle-ci est déclarée "final".


Je pratique ces règles et je trouve qu'elles me guident bien. 

Comment fonctionnent-elles ?

Il me semble que la règle 1) est évidente.

Les règles 2 et 3 appellent plus de commentaires. Au départ, je 
cherchais une règle qui empêche l'émiettement des imports. 
Mentalement, les classes qui nécessitent l'import de je ne sais 
combien de paquages pour les utiliser me semblaient difficiles à 
appréhender.

Par contre, si je n'ai besoin de n'importer que les classes proches 
de cette classe, donc, à priori, les classes de son paquage et des 
paquages des classes pères (désignées par le "extends"), c'est 
intellectuellement plus facile.

C'est comme ça que j'ai trouvé la règle 2), qui oblige à organiser 
les paquages en unités logiques. Si on veut appliquer cette règle 
sans s'obliger à intégrer ses paquages, cela devient rapidement 
impossible. C'est un bon signal d'alarme.

La règle 3) est là parce que la règle 2) est des fois difficile à 
appliquer. Dans ce cas, "final" veut dire en quelque sorte : "C'est le
bordel, faites ce que je dis mais ne faites pas ce que je fais !"

Ces règles n'empêchent pas les références circulaires, 
simplement, l'une des deux au moins est "final". Cela signifie que 
le comportement de l'une des deux au moins est parfaitement 
connu et fixe.

L'utilisation des classes "final" est à mon avis une bonne chose. 
Surtout si elle est associée à une classe "souple", qui respecte la 
règle 2). Les classes final donnent des objets dont on est sûr du 
comportement, tandis que les objets de règle 2) apportent la 
souplesse nécessaire et utile.


--
Hervé AGNOUX  hagnoux@mail.club-internet.fr
Faites vos sites avec des formulaires électroniques :
http://www.diaam.com