Classes Relations Aide

Version imprimable

28/02/2008, 19h30
Panaméen

Classes Relations Aide

Bonjour ,

Voila , jai un petit probleme , je ne sais pas comment faire , meme en ayant chercher auparavant

Donc voila j'ai une classe A et une classe B et une classe C

La classe A crée un tableau d'instance de B , et chaque instance de B crée une instance C.

Les 3 classes sont en faites reliées par composition à ce moment là.

Je veux en fait que C puisse voir B ... et ainsi executer des methodes de B.

Toutes les instances ont été par des new.

Donc ce que je voulais faire , c'est faire un getmonB dans A mais C ne pourra pas executer cette methode vu quil ne voit pas A ....

Please , jai vraiment besoin de votre aide.

cordialement
28/02/2008, 19h43
Mat007

Salut,

Peut-être que ce sujet un peu voisin pourrait t'aider ?

MAT.
28/02/2008, 22h12
Panaméen

Non car se n'est pas le meme genre de probleme

Citation:

Envoyé par Pugebad

Non car se n'est pas le meme genre de probleme

Ils sont un peu cousins quand même...

Code:

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
class B;
 
class C
{
public:
  explicit C( B& b ) : b_( b ) {}
 
private:
  C( const C& );
  C& operator=( const C& );
 
private:
  B& b_;
};
 
class B
{
public:
  B() : c_( new C( *this ) ) {}
 ~B() { delete c_; }
 
private:
  B( const B& );
  B& operator=( const B& );
 
  C* c_;
};

MAT.

Salut,

Tu pourrais envisager un truc du genre de:

Code:

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
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
class B;
class C;
class A
{
    public:
        A(/*arguments éventuels */){}
        ~A()
        {
             for(size_t i=0;i<btab.size();i++)
                 delete btab[i];
        }
         void addB(/*arguments éventuels */)
         {
              btab.push_back(new B(/*arguments éventuels*/);
         }
         size_t size() const
         {
              return btab.size();
         }
         void erase(size_t ind)
         {
               delete btab[ind];
               btab.erease(btab.betin+ind);
         }
         void clear()
         {
             for(size_t i=0;i<btab.size();i++)
                 delete btab[i];
         }
         B& operator[](size_t ind)
         {
             return *(btab[ind]);
         }
         /* autres méthodes */
    private:
        std::vector<B*> btab;
};
class B
{
    public:
        B(/*arguments éventuels*/):child(this
                                /*,autres arguments éventuels*/){}
        ~B(){}
        /* autres méthodes */
        C& child(){return child;}
    private: 
        C child;
}
class C
{
    public:
        C(B* pparent/*,autres arguments éventuels*/):pparent(pparent){}
        ~C(){}
        B& parent(){return *pparent;}
    private:
        B* pparent;
};

[EDIT] n'oublie pas de rendre ta classe A non copiable pour éviter les problèmes :p

29/02/2008, 13h49
Emmanuel Deloget
Histoire d'être complet, je tenais à dire que ce type de référence circulaire (puisqu'il s'agit de ça (B -> C -> B)) est à éviter. C'est souvent le signe d'un problème dans l'architecture logicielle (par exemple, B a plus d'une responsabilité; dans ce cas, mieux vaut casser B en deux classes B et B'; C et B se servent des services de B' et voilà - le tour est joué; enfin, encore faut-il que B' ait une sémantique propre).

La solution correcte consiste donc à revoir l'architecture logicielle - plus exactement la partie qui concerne la relation entre les classes A, B et C.
- vérifier que A, B et C n'ont qu'une responsabilité (respect du principe de responsabilité unique)
- vérifier si les dépendances ne sont pas due à la publication de détails d'implémentation dans les interfaces des classes (respect du principe d'inversion de dépendance).
Les cas ou les références circulaires sont obligatoires en C++ sont extrêmement rares. A l'heure actuelle, je n'ai vu que deux cas particuliers : l'implémentation du pattern visiteur tel que décrit dans le GoF (l'autre possibilité est décrite par RC Martin, qui propose un visiteur acyclique; celui-ci souffre d'autres défauts - il est à la limite de ne pas respecter le principe ouvert/fermé), et l'implémentation de shared_prt en relation avec weak_ptr (dans boost et dans le TR1). Dans le premier cas le problème est le langage lui même (pas de double dispatch natif, il doit donc être émulé); dans le second cas, c'est un parti pris au niveau de l'architecture, de manière à pouvoir créer un shared_ptr à partir d'un weak_ptr et vice-versa.

Tous les autres cas que j'ai vu abuse des fonctionnalités offertes par le langage et pourraient être mieux designés.