Discussion :

[tut]

Elle est inconnue des autres classes, mais la classe A l'a connait puisqu'elle la déclare...
Effectivement je pense que ça se rapproche de la notion de package, même si ce n'en pas un.

Je fais ce genre de déclaration souvent (en C++, mais peut importe le langage) : c'est pratique de pouvoir encapsuler les classes dans d'autres, pour des notions d'encapsulation, de visibilité, etc...

Je ne pensais pas que ça posait tant de problèmes en UML. Si c'est si difficile à représenter en UML, je présume qu'il doit être encore plus difficil d'arriver à faire générer du code correspondant à cela....

Ca ne se représente pas car c'est conceptuellement invalide. Définir une classe dans une autre classe implique que la classe contenue est inconnue du modèle,

ah bon, et pourquoi ?

La relation entre les classe dans le cas décrit est obligatoirement une aggrégation (ou composition), ce n'est pas parce qu'un objet est contenu dans un autre que cela impliquent que les appelants du conteneur savent ce qu'est le contenu.

C'est vrai qu'il y a une aggrégation entre A et B, A étant une collection de B.
Donc alors la question serait plutôt : comment représenter la portée de visibilité d'une classe en UML ?

Il faut que tu utilises un package.

Je ne pense pas, en C++ (mon langage d'implémentation), la notion de package peut se traduire par un namespace, et c'est trop lourd pour ce que je veux faire.

Merci pour les réponses en tout cas.

[n.patricia]

Ca ne se représente pas car c'est conceptuellement invalide. Définir une classe dans une autre classe implique que la classe contenue est inconnue du modèle,

ah bon, et pourquoi ?

Et bien on a tendance à l'oublier mais l'objet ce n'est pas le langage Java ou C++ ou autres. Il y a des concepts derrière l'objet et l'encapsulation de classe n'en fait pas partie sauf à ce que quelqu'un en démontre le contraire, ce qui n'est pas le cas depuis le début du thread.

[Franckintosh]

Elle est inconnue des autres classes, mais la classe A l'a connait puisqu'elle la déclare...
Effectivement je pense que ça se rapproche de la notion de package, même si ce n'en pas un.

Je fais ce genre de déclaration souvent (en C++, mais peut importe le langage) : c'est pratique de pouvoir encapsuler les classes dans d'autres, pour des notions d'encapsulation, de visibilité, etc...

C'est peut être pratique mais c'est pas propre.

Je ne pensais pas que ça posait tant de problèmes en UML. Si c'est si difficile à représenter en UML, je présume qu'il doit être encore plus difficil d'arriver à faire générer du code correspondant à cela....

Ce n'est pas difficile c'est impossible. Il ne faut pas mélanger modélisation et implémentation.

Ca ne se représente pas car c'est conceptuellement invalide. Définir une classe dans une autre classe implique que la classe contenue est inconnue du modèle,

ah bon, et pourquoi ?

La suite de ma phrase répondait à cette question, mais je vais la reformuler pour être sûr que cela soit plus clair.
Si ta classe B est définie dans ta classe A alors seule ta classe A connait B, donc le modèle (dans lequel est définie A) ne connait pas B, or si le modèle ne connait pas B tu ne peux pas dire dans ton modèle que A est une collection de B puisque B n'existe pas dans le modèle.

La relation entre les classe dans le cas décrit est obligatoirement une aggrégation (ou composition), ce n'est pas parce qu'un objet est contenu dans un autre que cela impliquent que les appelants du conteneur savent ce qu'est le contenu.
C'est vrai qu'il y a une aggrégation entre A et B, A étant une collection de B.
Donc alors la question serait plutôt : comment représenter la portée de visibilité d'une classe en UML ?

C'est le rôle des packages de gérer la visibilité entre éléments de modèle.

Je ne pense pas, en C++ (mon langage d'implémentation), la notion de package peut se traduire par un namespace, et c'est trop lourd pour ce que je veux faire.

Certes mais ce n'est pas parce que les packages peuvent se traduire en namespace qu'il faille les utiliser si cela est gênant. De plus il faut vraiment te poser la question de savoir pourquoi tu as besoin de cette non-visibilité. Si c'est juste pour que les appelants ne connaissent pas le type du contenu de ta collection et bien c'est inutile car si les appelants de A n'ont pas de lien direct avec ta classe B alors il est implicite qu'ils ne connaissent pas B. Seul le modèle connait (et doit connaitre) tous les éléments, par défaut chaque élément ne connait que lui-même. Pour qu'un élément en connaisse un autre il faut qu'il y est une association directe entre eux.

Merci pour les réponses en tout cas.

Ben de rien

[tut]

C'est peut être pratique mais c'est pas propre.

Voila une affirmation bien péromptoire, et qui n'engage que toi.

C'est le rôle des packages de gérer la visibilité entre éléments de modèle.

oui c'est vrai. Je devrai faire appel au paquetage, en fait.

Certes mais ce n'est pas parce que les packages peuvent se traduire en namespace qu'il faille les utiliser si cela est gênant. De plus il faut vraiment te poser la question de savoir pourquoi tu as besoin de cette non-visibilité. Si c'est juste pour que les appelants ne connaissent pas le type du contenu de ta collection et bien c'est inutile car si les appelants de A n'ont pas de lien direct avec ta classe B alors il est implicite qu'ils ne connaissent pas B

en fait, je pense que tu as raison, d'un point de vue UML.
Maintenant, d'un point de vue implémentation C++, je trouvais ça bien de pouvoir encapsuler des classes dans d'autres, et d'en contrôler la visibilité avec les public-protected-private. C'est utile quand tu fais des bibliothèques par exemple. Et c'est moins lourd que les namespace, ça revient à faire des sous-namespaces, en quelque sorte. Personellement je préfère utiliser un namespace pour un composant (l'ensemble d'une bibliothèque par exemple).
Mais là on n'est dans l'implémentation, et plus dans la modélisation.
Donc, je considère le débat comme clos.