Version imprimable
J'ai un diagramme de 3 classes :
A aggrège des objets B et des objets C
B aggrège des objets A
aggrègation != composition,
mais on m'a dit que le diagramme présente un cycle et que ça pose un problème.
Or si on y réflechit, le pattern composite(par exemple) devrait aussi présenter un cycle.
ClasseC
|
<>
|--<>ClasseA-------|
|-----ClasseB <>---|
Xavier
disons que je ne vois pas l'interet d'avoir A qui agrege B et ensuite B qui agrege A.
Tu dois avoir un probleme d'analyse, non ?
le patern composit est different car il y a la notion d'heritage :wink:
En fait plus précisément, j'ai un arbre qui contient un object A en racine
l'objet A contient (ou pas) plusieurs objets et B et plusieurs objets C.
Un exemple d'arbre peut être le suivant :
..........................A.........................
......................../.|.\.......................
......................C..B..B.....................
......................../.|.\...\...................
......................A..A..A..A.................
...................../|\..|...|...|\...............
..................C.C.C.C..C..C.C...........
On voit donc que les noeuds sont des objets A ou B, et que par étages, ce sont soit des objets A, soit des objects B.
Les objets A et B ont bien des sémantiques différentes.
Les objets C sont les feuilles de l'arbres.
Le diagramme de classe précédemment représente bien (je pense) mon arbre.
La question est : est-ce que le diagramme UML fourni au début est valide ?
- Eventuellement, si ce n'est pas le cas, comment modéliser mes classes ?
- Eventuellement, si il y a possibilité de faire un diagramme plus propre, comment serait-il fait (sachant que toute modification du diagramme de classe entraine des modifications dans mon code qui marche très bien) :)
Je précise que
- un objet A ne peut aggréger que des objets B et des objets C. :!:
- un objet B ne peut aggréger que des objets A (pas de B ni de C). :!:
Les feuilles de l'arbre sont uniquement les objets C.
Je ne vois pas comment m'en sortir autrement qu'avec le diagramme de classe du début de la discussion.
il faut que tu revois ton analyse. Explique ton réel sujet si ca ne te dérange pas, ca peut aider a trouver une solution car A B C ca ne parle pas trop :)
Si tu as à faire a une arborescence utilisie le pattern composite. Pas besoin de réinventer la roue. :D
En gros, la structure de donnée(celle de l'arbre) a été fixée.
Je n'ai pas le droit d'en changer.
Je précise :
quand on veut implémenter une liste chainée simple, on doit écrire par exemple une classe Cellule.
Dans mon exemple les différentes classes je les nomme A, B , et C comme j'ai du nommer la classe Cellule.
L'arbre représente une entrée à donner à une application de simulation.
Cette entrée possède les données sur une ou plusieurs populations ainsi que des données globales (des paramètres en plus ou des infos complémentaires).
Cet arbre est stocké dans un fichier XML que l'on doit envoyer à l'application de simulation.
Je répète que l'arbre et les règles de structuation sont fixées.
Un exemple concret très simple d'arbre pourrait être
.........................A....................... ici A = Entrée
......................../.|.\....................
......................C..B..B................. C=date B= population1 B=population2
......................../.|.\...\...............
......................A..A..A..A............. A = individus
...................../|\..|...|...|\...........
..................C.C.C.C..C..C.C....... C=les attributs des individus
les attributs des individus peuvent être une opinion une incertitude, etc ... et c'est pour cela que l'on peut les représenter par des objets C (qui sont les éléments les plus élémentaires de la structure et en même temps évidemment les feuilles de l'arbre.)
Le problème d'un pattern composite, c'est qu'il ne permettrait pas de distinguer les types d'objets A et B qui n'ont rien à voir :
=> L'objet A est un objet complexe qui possède une liste d'objets B et une liste d'objets C.
=> L'objet B est une liste d'objet A.
Ces 2 objets (A et B) sont donc différents par leur méthodes et leurs attributs.
Donc (selon moi) il ne convient pas du tout d'utiliser le pattern composite qui ne se serait appliqué que si les objets A et B pouvait hériter d'une classe commune (i.e avoir suffisamment de point commun).
Disons que le Design Pattern ne permettrait pas de faire un arbre avec 2 étages:
un étage (dans l'exemple niveau 1 et 3) ou il n'y a que des objets A
un étage (dans l'exemple niveau 2 et 4) ou il n'y a que des objets B et C
Pour comprendre il est peut être nécessaire de relire le tout.
Je suis désolé si je ne suis pas très clair. Je sais que vu de l'extérieur c'est pas forcément évident. :)
c bon, je pense que tu n'as pas besoin de preciser :wink:Citation:
Dans mon exemple les différentes classes je les nomme A, B , et C comme j'ai du nommer la classe Cellule.
Je ne voit pas exactement où est ton probleme.
Tu as un cycle mais ce n'est pas de ta faute car la structure t'a été fourni. :DCitation:
Je répète que l'arbre et les règles de structuation sont fixées.
En plus ton programme tourne et je ne pense pas que tu ai envie de te rettaper une analyse et reprogrammer derriere.
Donc voilà :)
Perso je trouve la structure bizarre mais c possible que je ne cromprenne rien aussi :)
Je sais pas trop si tu as compris la structure d'arbre, mais je te remercie en tout cas d'avoir tenté de répondre à ma question. N'hésites pas à me répondre si tu as des trucs à dire à propos de ce sujet. :bravo:
Et même tous les lecteurs aussi, n'hésitez pas ! :)
Le diagramme présente un cycle, c'est vrai que cela peut être gênant si laisser comme tel, mais la solution à ton problème est là, nul besoin de changer ton diagramme il suffit juste de rajouter des contraintes à tes relations. La seule qui n'a pas encore été évoquée dans ce sujet est que "Si A contient un B alors A ne peut pas contenir de C".Citation:
Envoyé par FarookFreeman
En fait, c'est pas exactement ça : il n'y a pas de contrainte la dessus.Citation:
La seule qui n'a pas encore été évoquée dans ce sujet est que "Si A contient un B alors A ne peut pas contenir de C".
L'objet A, il contient des objets B (et/ou) des objets C.
Le (et/ou) est indépendant de toute règle, et ne dépend que du désir de l'utilisateur quand il souhaitera remplir son arbre.
De même, les contraintes, c'est lui qui les fixera tout simplement par le remplissage de l'arbre.
Je ne vois pas trop quel type de contrainte je pourrais mettre en plus, sinon.
Enfin, merci de m'avoir dit que le diagramme est le bon même s'il présente un cycle.
Euh en fait je m'aperçois que je t'ai dit n'importe quoi sur la contrainte, je me suis laissé tromper par ton schéma d'exemple plein de C partout. :oops:
Par contre je maintiens que le diagramme est correct, la seule chose à surveiller est d'éviter d'aggréger un A dans un B qui a ce même A dans ses ascendants (de même pour les B dans les A). Le plus sûr pour éviter cela est la composition plutôt que l'aggrégation mais là dépends si tes objets supportent la composition ou pas.
C'est exactement cela.
La conclusion à laquelle je suis arrivé.
Bien sur cela entraine de faire tres attention à ne pas faire réellement un cycle entre 2 objets. :)
Je travaille en java, mais en fait le problème est plus compliqué que ça.
Ca n'aurait pas d'intérêt je pense que j'explique d'intégralité, ce serait embêter les gens pour rien.
En tout cas merci pour ta confimation. 8)
Je vois que le problèeme a été difficile a expliquer et difficile a saisir par les autres aussi.
une classe C et B heritent de A.
B par exemple contient des obejt de type A (A est et pure absatraite).
La question n est pas de se poser la question de l' interet de ca. celui qui en a besoin le sait lui.
Au fait il s'agit du design pattern Composite de Gamma et al. alors il ne faut pas dire simplement que l'analyse n a pas été bien faite.
Je suis entrain d'y reflechir actuellement.
Le problème en C++, c'est que dans ce cas, C et B ne peuvent etre utilisées dans A et heriter de cella-la en même temps.
en passant ce je relance le problèeme je ne pense pas qu il soit resolu.
C'est exactement contraire à ce qui a été exposé.Citation:
Envoyé par doxo
C'est a celui qui a poser le problème de décider du passage à cet état ;-).Citation:
en passant ce je relance le problèeme je ne pense pas qu il soit resolu.