Il faut faire la distinction entre le "possesseur" (celui qui peut -- éventuellement -- créé un nouvel élement) et "l'utilisateur" (celui qui peut uniquement accéder à un élément)
En UML, on fera la distinction entre "l'agrégation" et "la composition", qui sont toutes les deux des relation d'association:
L'agrégation est la relation qui permet ... d'accéder à un élément alors que l'on n'en est pas le propriétaire, alors que la composition implique que l'on est réellement le propriétaire de l'élément ou, si tu préfères si l'élément ne peut pas exister sans la classe envisagée.
Ainsi, si tu as une voiture, la voiture peut être considérée comme "le propriétaire" du moteur, car, quand la voiture part à la casse, son moteur y part avec elle.
On se rend donc bien compte qu'il n'y a de sens à construire un moteur que... si il y a une voiture dans lequel le mettre. Ou, si tu préfères, que l'existence même du moteur va dépendre ... de l'existence de la voiture qui l'utilise.
De la même manière, si on considère les parents et les enfants, on se rend compte qu'un enfant ne peut naître que... ses parents existent (et ont -- qui sait -- été batifoler dans les près au clair de lune :D)
En C++, ce genre de relation -- la composition en UML -- sera représentée par une donnée fournie sous forme de valeur, ou , le cas échéant, par une collection de données fournies sous forme de valeurs:
class Parent{
public:
/* ... */
private:
Enfant gauche;
Enfant droite;
};
/* OU - OU - OU */
class Parent{
public:
/* ... */
private:
std::vector<Enfant> enfants;
};
A l'inverse, la relation qui unit l'enfant à son (ou ses) parent est la même que celle qui unit le moteur à la voiture : il s'agit d'une agrégation, car l'enfant (le moteur) ne peut pas "posséder" son parent (la voiture), vu que nous venons de déterminer que ... c'est le parent (la voiture) qui possède l'enfant (le moteur).
Pour représenter cette relation, nous disposerons de deux solutions:
Celle que nous devrions -- idéalement -- privilégier autant que possible, mais qui n'est applicable que
si les notions de "parent" et "d'enfant" sont effectivement représentées par deux types différents (ex: la voiture et le moteur)
si nous pouvons garantir que l'enfant aura toujours un parent auquel faire référence (le moteur et la voiture, encore une fois)
si nous pouvons garantir que le parent ne changera pas durant tout le temps d'existence de l'enfant
qui consiste à permettre à l'enfant de "connaitre" son parent sous forme d'une référence (éventuellement constante):
class Voiture;
class Moteur{
public:
/* ...*/
private:
Voiture & laVoiture;
};
class Voiture{
public:
/*...*/
private:
Moteur leMoteur;
};
et la solution qui offre beaucoup moins de garanties, et qui est donc beaucoup plus "souple" (et plus dangereuse) d'utilisation, car:
elle permet à l'enfant et au parent d'être de même type
elle permet à l'enfant de ne pas avoir de parent
elle permet éventuellement à "changer de parent" durant sa durée de vie
et qui consiste à représenter le parent sous forme d'un pointeur:
class Noeud{
public:
/* ...*/
private:
Noeud * parent; // le parent peut ne pas exister
Noeud * gauche; // le noeud courant peut ne pas avoir
// d'enfant à gauche
Noeud * droite; // le noeud courant peut ne pas avoir
// d'enfant à gauche
};
class Arbre{
public:
/*...*/
private:
Noeud racine; // un arbre dispose ** forcément **
// d'un noeud "racine", qui n'a --
// clairement -- pas de parent et qui
// n'a dans u premier temps
// sans doute ni enfant à gauche ni
// enfant à droite
};
Ce qui se conçoit bien s'énonce clairement. Et les mots pour le dire viennent aisément.Mon nouveau livre : Coder efficacement - Bonnes pratiques et erreurs à éviter (en C++)Avant de faire ce que tu ne pourras défaire, penses à tout ce que tu ne pourras plus faire une fois que tu l'auras fait
Votre message ne comporte pas ou peu de formules de politesse (« Bonjour », « Merci », « Au revoir », etc.). Les règles du site exigent que chaque nouveau message comporte un minimum de politesse. Après tout, les gens qui répondent le font gratuitement, sur leur temps libre. Ils méritent bien un minimum de considération, n'est-ce pas ?
merci @koala01, je vais essayer de résumer ton message pour voir si j'ai bien compris:
il y a 2 solutions à mon problème
soit on met dans l'objet enfant une référence (constante ou pas) de l'objet parent,
soit on crée une classe extérieure ayant des pointeurs pouvant accéder à la classe parent (mais dans ce cas là comment avoir l'accès aux attributs privés et protégés?).
soit on met dans l'objet enfant une référence (constante ou pas) de l'objet parent,
soit on crée une classe extérieure ayant des pointeurs pouvant accéder à la classe parent (mais dans ce cas là comment avoir l'accès aux attributs privés et protégés?).
Une classe définie dans une autre n'a aucun privilège ni aucun lien avec la classe englobante, elle a les mêmes droits que si elle est extérieure. Dans les 2 cas, on n'a pas accès aux membres protégés ou privés. Seul friend permet cet accès, et c'est souvent à éviter. Peut-être que tu pourrais expliquer ton besoin.
Une classe définie dans une autre n'a aucun privilège ni aucun lien avec la classe englobante, elle a les mêmes droits que si elle est extérieure. Dans les 2 cas, on n'a pas accès aux membres protégés ou privés. Seul friend permet cet accès, et c'est souvent à éviter. Peut-être que tu pourrais expliquer ton besoin.
Merci,
J'ai posé la question car dans mon code j'ai utilisé deux blocs "struct" pour trier mes méthodes mais apparemment ce serais une pratique à éviter.
Le Tout est souvent plus grand que la somme de ses parties.
En recherche d'emploi.
En recherche d'emploi.