Salut,
La réponse à ta question prend plusieurs facettes... Je vais essayer de les passer en revue.
Du seul point de vue du code:
Oui, si tu dispose, dans une classe A d'une fonction membre permettant de récupérer un B, tu peux effectivement profiter de l'objet récupéré par cette fonction membre afin d'appeler un comportement donné au départ de cet objet, et travailler "en cascade" sous une forme proche de
int i=a.getB().getC().getD()/* on peut aller aussi loin qu'on veut :D */.getMonInt();
Cependant, tel qu'il est écrit, ton code présente des désagréments facheux: il effectue des copies en grand nombre des différents objets renvoyés par les différentes fonctions membres.
L'idéal, dés que l'objet est plus complexe qu'un type primitif, est donc de renvoyer une référence vers l'objet contenu.
Cependant, si tu renvoies une référence "simple" sur l'objet contenu, toute modification de l'objet que tu pourrais entreprendre sera répercutée... sur la variable correspondante dans le contenant.
Or, si tu modifies une variable du contenant, tu modifie, de facto (ou du moins, jusqu'à preuve du contraire)... le contenant, et cette modification échappe à tout contrôle de la part du contenant.
Il est donc préférable de prendre des engagements selon lesquels la référence renvoyé ne sera pas modifiée, et que l'appel de la fonction ne modifiera pas le contenant.
Pour y arriver, il "suffit" de déclarer la référence renvoyée et la fonction qui la renvoie constantes, ce qui permettra, de plus, d'invoquer la fonction en question au départ... d'un contenant constant.
Au final, la fonction membre extraireB(id) devrait donc prendre la forme de
1
2
3
4
| B const & extraireB(id) const;
^ ^
| |
(1) (2) |
(1) indique que l'objet renvoyé ne pourra pas être modifié
(2) indique que la fonction s'engage à ne pas modifier l'objet de type A
Enfin, il existe un concept que l'on appelle pompeusement la "loi demeter", également connue comme la "loi de la connaissance minimale".
En gros, cette loi explique que, si un objet A manipule en interne un objet B, il n'y a, a priori, aucune raison à ce que A expose le B.
L'exception majeure étant le fait que les services attendus de A soient, justement, de servir de... collection de B (et encore, on n'exposera pas forcément le B en tant que tel, mais plutôt sous la forme d'un itérateur permettant d'accéder aux différents éléments présents dans la collection 
).
Quoi qu'il en soit, cette loi indique aussi que si un A manipule un (ou des) B, et que C manipule des A, il n'y a, a priori, aucune raison pour que C ait connaissance de l'existence de B.
Mais cela va également dans l'autre sens: il n'y a, a priori toujours, aucune raison pour que si C manipule un B, il n'ait connaissance... du A dont est issu le B manipulé.
Ainsi, nous remarquons trois situations possibles concernant C:
Soit, C manipule expressément un A, et se contente d'appeler des fonctions membres de A, sous une forme proche de
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
| void C::doSomething(A const & a)
{
a.print(); // A::print affiche l'ensemble de son contenu
}
void C::foo(A & a)
{
int i;
a.add(i); // A::add converti le int en B et l'ajoute à sa collection
}
void C::bar(A & a)
{
int id;
a.remove(id); // A::remove supprime le B portant l'ID id de sa collection
a.clear(); // A::clear vide entièrement sa collection de B
} |
soit C manipule un B unique à chaque appel sous la forme de
1
2
3
4
5
6
7
8
9
10
11
12
| void C::foo( B /* const &*/ b)
{
x=b.valeur(); // x est déclaré comme un int
}
/* qui sera appelée par ailleurs sous une forme proche de */
int main()
{
A a;
/* remplicage de A */
C c;
c.foo(a.getB(id));
} |
Soit enfin, C manipule une gamme d'objets B, et, dans ce cas, tu as sans doute meilleur temps de ne faire aucune présomption quant à la provenance de cette gamme et de "simplement" estimer qu'il s'agira d'itérateurs ayant une sémantique de pointeurs:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
| class C
{
public:
template <iterator>
void makeAll(iterator begin, iterator end)
{
while(b!=e)
{
(*b).doIt(); // la fonction qui nous intéresse de B
++b; // on passe au suivant
}
}
};
/* cela permet de travailler avec n'importe quelle sources: */
int main()
{
C c;
A a;
/* remplicage du A */
c.MakeAll(a.begin(),a.end()); /* A::begin et A::end renvoient
* respectivement un itérateur sur le
* premier et sur ce qui suit le dernier
* élément de la collection
*/
/* mais cela pourrait fonctionner si nous partions d'un tableau "C style"
*/
B * tab=new B[10];
c.MakeAll(tab,tab+10);
delete[] tab;
/* et si, pour une raison ou une autre, D venait lui aussi à agir
* comme une collection de B, cela reviendrait au même :
*/
D d;
/* remplicage de d*/
c.MakeAll(d.begin(),d.end());
return 0;
} |
Maintenant, c'est à toi de voir dans quelle situation tu te trouve par rapport à ton cas particulier 
Accéder aux membres d'une classe à partir d'une autre
Répondre avec citation
)
A méditer: La solution la plus simple est toujours la moins compliquée
Partager