Difference Composition/Agregation et méthode Clone()

Hello,

j'ai des ptites interrogations qui me trottent dans la tete :? :

Question 1.

Quel est la difference entre la composition et l'agregation?

On m'a dit que dans la composition, quand on détruit le composé A, tous les composants B sont détruits.
Dans le cas de l'agrégation, lorsqu'on détruit A(l'agrégé?), les B (agregats?) ne le sont pas...
est-ce que ça se résume à ça en gros??

Du coup, comment on implémente ça en JAVA?
Pour implémenter la composition, les composés sont des champs de L'objet Composant.
Mais pour implémenter une agregation, ce sont aussi des champs sauf que cette fois-ci ce serait des COPIES?

Question 2.

Grossièrement, j'ai un Objet de classeA avec pour champ

ClasseA
{
int code;
}

J'ai un Objet de classeB avec pour champ

ClasseB implements Cloneable
{
String description;
ClasseA item;

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

// une méthode clone() implémentée de la manière suivante : public Object clone() { try { return super.clone(); } catch(CloneNotSupportedException e) { throw new InternalError(); } }

---

}

Si on fait :

Code:

---

1 2 3 4

ClasseB objB = new ClasseB("ceci est un objet de classe classeB", new ClasseA());   ClasseB objB2 = objB.clone();

---

alors, ma question :

"obj2" possede :

un champ "description"(de type primitif String) qui a la meme référence que celui de "objB"?
=> normalement, je dirai non car le champ 'description' est d'un type primitif..??

un champ "item"(de type non primitif) qui a la meme référence que celui de "objB"?
=> ça je sais pas du tout..., mais si c'est la meme reference, cela voudrait dire qu'il faut reimplementer la méthode clone() quand le champ n'est pas de type primitif???


OK je vous l'accorde.. mes questions sont à la fois interrogatives et affirmatives mais c'est flou dans ma tête, et j'ai besoin de savoir si je ne dis pas de bêtises .. merci de m'éclairer un peu !!!!! :aie:

Hum je n'ai pas mes bouquins sous la main mais bon... Alors je vous prie de m'excuser si j'ecris trop de betises :

Citation:

---

Quel est la difference entre la composition et l'agregation?

On m'a dit que dans la composition, quand on détruit le composé A, tous les composants B sont détruits.

---

En fait les composants B sont des sous-parties de A (au sens A est compose de un ou plusieurs B). Je crois que le Design Pattern Explained (Design Pattern par la Pratique en vf) indique en exemple qu'une voiture c'est composee, en autre, des roues, d'un moteur, etc...

Citation:

---

Dans le cas de l'agrégation, lorsqu'on détruit A(l'agrégé?), les B (agregats?) ne le sont pas...

---

En fait les composants B sont juste contenus dans A (au sens A contient des B). Je crois que le Design Pattern Explained (Design Pattern par la Pratique) indique en exemple qu'un aeroport ca peut contenir/recevoir des avions mais qu'aucunement les avions ne constituent des sous-parties de l'aeroport.

Citation:

---

Du coup, comment on implémente ça en JAVA?

Pour implémenter la composition, les composés sont des champs de L'objet Composant.
Mais pour implémenter une agregation, ce sont aussi des champs sauf que cette fois-ci ce serait des COPIES?

---

Alors le plus marrant c'est, qu'en general, en Java on s'en tape un peu car il n'existe pas de destructeurs ou de methode permettant de liberer explicitement la memoire (ce qui peut poser pb en C++* si l'objet est detruit ailleurs par exemple ou au contraire si on oublie de le detruire lors de la destruction du composant principal). Donc la plupart du temp il n'est pas necessaire d'avoir des copies. On peut donc utiliser des references, des listes, des table de hashage, ... ou tout autre conteneur pour les sous-composants ou sous-contenus.

*Mais bon... je crois qu'on peut contourner une partie du pb en se forcant a retourner des references ou des references constantes plutot que des pointeurs. Apres si on est pas sur ou en multi-thread => copie/clone.

La distinction entre composition et aggregat peut donc etre assez vague suivant les cas et les usages parfois. A toi donc de bien indiquer dans ta doc si les arguments passes en parametre et en valeur de retour des methodes sont des copies/clones ou les originaux.

Ce qui est plus important pour toi a la rigueur c'est que dans une composition, qqun a l'exterieur ne modifie pas un sous-composant B de A sans prevenir le composant pricipal ou ne mette pas le B dans un etat incompatible avec A. Un bonne methode est d'utiliser un couple d'interfaces Item (interface permettant juste la consultation via des get ~ equivalent d'une reference constante en C++) et MutableItem (interface permettant egalement la modification via des set) associee a une seule implementation concrete (DefaultMutableItem) et ensuite d'utiliser les types appropries la ou il faut dans les methodes (pas mal de modeles de composants Swing utilisent cela).

==============

Citation:

---

un champ "description"(de type primitif String) qui a la meme référence que celui de "objB"?
=> normalement, je dirai non car le champ 'description' est d'un type primitif..??

---

Une String est un objet et non pas un literral. Donc a priori la reference pointe sur le meme objet.

Citation:

---

un champ "item"(de type non primitif) qui a la meme référence que celui de "objB"?
=> ça je sais pas du tout..., mais si c'est la meme reference, cela voudrait dire qu'il faut reimplementer la méthode clone() quand le champ n'est pas de type primitif???.

---

D'ou le fait qu'il faille faire tres attention avec clone() nottement quand ton objet contient des List, Map ou d'autres Collections. Oui, suivant les usages, il faut parfois/souvent surcharger la methode clone() pour faire des copies supplementaires des sous-composants (clonage en profondeur).