[C++] Héritages et classes

**Aspic** · 18/11/2010, 22h08

Bonsoir,

J'ai un petit problème de gestion de mes classes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
class typeMonde
{
protected:
Zone* salle;
};
 
class Donjon : public typeMonde
{
private:
int nbCle;
};
 
class Zone;
{
 // ....
};
 
class ZoneDonjon : public Zone
{
// ...
};

Donc on a un Donjon (Donjon) qui est un type de monde (Donjon qui hérite de typeMonde).
Chaque monde possède une salle et il existe plusieurs type de salle (Zone) dont la salle Donjon (ZoneDonjon qui hérite de Zone).

Question : Dans la classe ZoneDonjon, j'ai besoin d'accéder à l'attribue "nbCle" qui se trouve dans la classe Donjon. Comment faire intelligemment, sachant que j'ai besoin de modifier cet attribue dans la classe ZoneDonjon ?

Le but est dans le cadre d'un jeu 2D, de gérer un donjon. Et dans un donjon, il y a des salles et une seule salle qui est "active", c'est à dire la salle où on joue. Et j'ai besoind 'avoir accès aux nombre de clés totale du donjon dans chaque salle.

Voilà, je suis perdu dans mes classes

Merci

**Eusebius** · 18/11/2010, 22h39

Envoyé par Aspic

Question : Dans la classe ZoneDonjon, j'ai besoin d'accéder à l'attribue "nbCle" qui se trouve dans la classe Donjon. Comment faire intelligemment, sachant que j'ai besoin de modifier cet attribue dans la classe ZoneDonjon ?

Il y a plusieurs manières.
Celle qui a ma préférence, et qui est la plus "classique" : tu ajoutes un getter et un setter (méthodes publiques getNbCle() et setNbCle(int)) dans la classe Donjon. Ca te donne un peu de contrôle sur les accès et les modifications, si tu as des tests à faire pour vérifier que les modifs sont cohérentes par exemple.

Sinon, tu peux déclarer la classe ZoneDonjon ou certaines de ses méthodes comme "friend" de Donjon, mais à mon sens c'est une brèche dans la "sécurité" objet en C++.

Sinon, encore pire à mon sens, tu repasses nbCle en public, c'est-à-dire que tu renonces tout-à-fait aux fonctionnalités de contrôle d'accès pour cette variable membre.

**Aspic** · 18/11/2010, 22h58

Je suis peut être bête mais aucune de ses solutions ne va marcher...
Si par exemple, je le passe en public, comment j'y accède dans ma classe ZoneDonjon, vu qu'il n'y a pas de liens avec la classe Donjon ?

**Eusebius** · 19/11/2010, 08h45

Envoyé par Aspic

Je suis peut être bête mais aucune de ses solutions ne va marcher...
Si par exemple, je le passe en public, comment j'y accède dans ma classe ZoneDonjon, vu qu'il n'y a pas de liens avec la classe Donjon ?

Ah ok, je n'avais pas compris ton problème.
Eh bien je ne connais pas ton application, mais si ZoneDonjon n'est créée que relativement à un Donjon donné, cela ferait sens de lui faire un constructeur prenant en paramètre un pointeur vers le donjon en question, et de le mémoriser dans une variable membre (privée). Ou alors, de faire ce lien plus tard via une méthode du type setDonjon(Donjon *), ou encore de passer un Donjon* en paramètre à la fonction qui doit accéder à nbCle... Tout dépend du lien que tu veux faire entre l'instance de ZoneDonjon et l'instance de Donjon. Il faut que tu formalises ce lien, c'est un problème de conception plus qu'un problème de C++. Un petit gribouilli en pseudo-UML, pour prendre conscience des liens et de leurs cardinalités, t'aiderait sans doute.

**AF_2.8** · 19/11/2010, 09h53

Je pense que Eusebius à raison.
C'est avant tout un problème de conception.
POur moi si il parait logique que ce soit le donjon qui gère les clés, il est normale que ce soit lui qui possède l'attribut, néanmoins, si la classe Zone à besoin de connaitre le nombre de clé, il serait intéressant que tu rajoute à la classe Zone un pointeur sur le nombre de clé géré par la classe TypeMonde.

Pour savoir quelle est la meilleure solution, il faut en savoir plus sur le rôle des clés et pourquoi/quand la classe Zone en a besoin.

**Aspic** · 19/11/2010, 12h14

Merci pour vos réponses.

Alors effectivement, pour Koala01, tu as bien compris, la zoneDonjon gère la partie SPECIFIQUE des "monde donjon" (exemple : portes, portes à clé, objets spécifiques aux donjons comme les clés...) alors que la zone gère les parties COMMUNES aux différents type de monde (exemple : enemies, objets de base...).

Et oui il doit bien y avoir une relation entre zoneDonjon et Donjon et justement je suis coincé car je suis nul en conception et je n'ai jamais fait d'UML (je ne suis qu'en première année d'ingénieur

, c'est l'année prochaine l'UML).

Alors passé un pointeur Donjon* dans zoneDonjon, j'y ai pensé mais je ne trouve pas que c'est une bonne solution étant donné que je n'ai besoin d'avoir accès qu'à un petit nombres d'attribues de la classe Donjon.

Utilisez un DL, je ne sais pas de quoi tu voulais parler Koala01

Utilisez les amis, je connais vaguement le principe mais on m'a dit de s'en méfier donc à voir.

J'ai trouvé une solution temporaire, c'est de déclarer les attributs donc j'ai besoin en static et créer des getter et setter statiques pour modifier les attribues. Je ne sais pas si c'est une bonne solution mais ca marche

Est ce que cela viole le principe d'encapsulation ? (bien que j'ai créé des getter et setter, n'importe qui peut modifier mes attributs...)

Sinon je vais tenter de précision mon projet :

Je gère un donjon dans un zelda. Pour ceux qui connaissent les zelda, il y a des salles (ou zones) dans un donjon et le principe d'un zelda c'est qu'on traverse les salles une à une en "scrollant" donc a chaque "scroll" (ou changement d'écran si vous préférez), la classe zoneDonjon est détruite puis recréée avec les nouvelles infos de la zone.

Mais il y a des portes à clés dans un donjon avec des clés. Ce sont des objets spécifiques aux donjons qui n'existent pas dans les autres type de monde.

Question : Où gérer les clés et l'ouverture des portes à clé ?

Actuellement, les clés sont gérés dans Donjon et l'ouverture des portes à clé dans zoneDonjon puisque une porte à clé fait partie d'une zone (ou salle).

J'espère avoir été clair sinon n'hésitez pas à me le dire

Merci

**Emmanuel Deloget** · 19/11/2010, 12h26

Envoyé par Aspic

Bonsoir,

J'ai un petit problème de gestion de mes classes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
class typeMonde
{
protected:
Zone* salle;
};
 
class Donjon : public typeMonde
{
private:
int nbCle;
};
 
class Zone;
{
 // ....
};
 
class ZoneDonjon : public Zone
{
// ...
};

Donc on a un Donjon (Donjon) qui est un type de monde (Donjon qui hérite de typeMonde).
Chaque monde possède une salle et il existe plusieurs type de salle (Zone) dont la salle Donjon (ZoneDonjon qui hérite de Zone).

Question : Dans la classe ZoneDonjon, j'ai besoin d'accéder à l'attribue "nbCle" qui se trouve dans la classe Donjon. Comment faire intelligemment, sachant que j'ai besoin de modifier cet attribue dans la classe ZoneDonjon ?

Le but est dans le cadre d'un jeu 2D, de gérer un donjon. Et dans un donjon, il y a des salles et une seule salle qui est "active", c'est à dire la salle où on joue. Et j'ai besoind 'avoir accès aux nombre de clés totale du donjon dans chaque salle.

Voilà, je suis perdu dans mes classes

Merci

Tu énonce les relations suivantes:

un Donjon est un typeMonde.
un typeMonde possède plusieurs Zone
une ZoneDonjon est une Zone.

Ensuite, tu poses la question : comment ZoneDonjon peut-elle obtenir des informations à partir de Donjon ?

La réponse est : elle ne peut pas. Il existe une relation entre Donjon et ZoneDonjon (un Donjon contient plusieurs ZoneDonjon), mais l'inverse n'est pas vrai - et c'est tant mieux.

Imagine que tu te réveilles dans une pièce complètement fermée. Tu n'as pas de fenêtre, pas de porte visible (on a construit la pièce autour de toi pendant que tu dormais), tu n'entends aucun son. Bref : tu est isolé. Toi et cette pièce, c'est le contenu. Ce qu'il y a à l'extérieur de cette pièce, c'est le contenant.

Pourrait-tu compter le nombre de personnes du contenant qui sont situées à moins de 5m du contenu ? Non, parce que tu n'a strictement aucun moyen de le savoir.

Ton problème est similaire : un contenu ne peut pas savoir ce que renferme le contenant, à moins que le contenant ne l'en informe ou qu'il ait un moyen de récupérer cette information par lui même.

Le problème de la seconde solution est que ça impose qu'il existe une relation entre ZoneDonjon et Donjon. Hors il existe déjà une relation entre Donjon et ZoneDonjon, et c'est une mauvaise idée d'implémenter la relation inverse (pour un tas de très très bonnes raisons). Donc on va éviter ça.

La première solution paraît plus intéressante ; le contenant trouve un moyen de transférer des informations au contenu. Etant donné que le contenant sait beaucoup de chose sur le contenu - et en particulier, dans ton cas, il sait ce qu'est le contenu -, il est libre d'implémenter la fonctionnalité qu'il souhaite pour le faire.

Dans ton cas précis, je ferais ceci :

Lorsqu'il contruit un ZoneDonjon, Donjon lui transmet les informations qu'il souhaite partager.
Dès qu'une de ces informations est modifiée, Donjon avertit ZoneDonjon de cette modification

En gros, le code devrait ressembler à :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
 
class Dungeon
{
  Dungeon() : info1(0), info2(0)
  {
     do N times:
       zones.add(new DungeonZone(info1, info2...) ;
  }
  void changeInfo1()
  {
     activeZone.changeInfo1(info1);
  }
private:
  info1;
  info2;
  ...
  list<DungeonZone*> zones;
  DungeonZone* activeZone;
};
 
class DungeonZone
{
public:
  DungeonZone(info1, info2...)
  { ... }
  void changeInfo1(info1) { ... }
  void changeInfo2(info2) { ... }
};

Ou quelque chose de ressemblant qui correspond à tes besoins.

**koala01** · 19/11/2010, 12h38

Envoyé par Aspic

Merci pour vos réponses.

Alors effectivement, pour Koala01, tu as bien compris, la zoneDonjon gère la partie SPECIFIQUE des "monde donjon" (exemple : portes, portes à clé, objets spécifiques aux donjons comme les clés...) alors que la zone gère les parties COMMUNES aux différents type de monde (exemple : enemies, objets de base...).

Et oui il doit bien y avoir une relation entre zoneDonjon et Donjon et justement je suis coincé car je suis nul en conception et je n'ai jamais fait d'UML (je ne suis qu'en première année d'ingénieur

, c'est l'année prochaine l'UML).

Qu'est-ce qui t'empêche de prendre un peu d'avance et de t'y intéresser par toi-même

Il y a une section entièrement dédiée sur le site, et ce ne sont pas les tutoriaux (plus ou moins bien faits) qui manquent sur le net

Tu remarquera d'ailleurs relativement vite que le but de tes études est de te donner les bases et de "t'apprendre à apprendre" sur base du "peu" que l'on t'aura donné

(bon, j'exagère un peu, mais je suis quand même pas loin de la vérité

)

Alors passé un pointeur Donjon* dans zoneDonjon, j'y ai pensé mais je ne trouve pas que c'est une bonne solution étant donné que je n'ai besoin d'avoir accès qu'à un petit nombres d'attribues de la classe Donjon.

Utilisez un DL, je ne sais pas de quoi tu voulais parler Koala01

Je parlais d'un DP et non d'un DL...

C'est l'abréviation de Design Pattern, ou, si tu préfère en français: patron de conception.

Il s'agit de patrons qui reviennent de manière tellement récurrente dans les problèmes de conception qu'on en est arrivé à les "standardiser", ou du moins à trouver une manière d'exprimer le problème auquel on est confronté et la solution à y apporter de manière claire et précise

Il existe d'ailleurs un tutoriel sur le site, mais, comme je n'ai pas l'adresse en tête, je te conseillerais bien de faire un tour sur la page des tutoriels

Utilisez les amis, je connais vaguement le principe mais on m'a dit de s'en méfier donc à voir.

J'ai trouvé une solution temporaire, c'est de déclarer les attributs donc j'ai besoin en static et créer des getter et setter statiques pour modifier les attribues. Je ne sais pas si c'est une bonne solution mais ca marche

Est ce que cela viole le principe d'encapsulation ? (bien que j'ai créé des getter et setter, n'importe qui peut modifier mes attributs...)

Ouggghhh... là, tu pars complètement en vrille...

j'ai scindé la discussion de manière à ouvrir le débat sur l'amitié, n'hésite pas à y jeter un oeil afin de te faire ton idée

Sinon je vais tenter de précision mon projet :

Je gère un donjon dans un zelda. Pour ceux qui connaissent les zelda, il y a des salles (ou zones) dans un donjon et le principe d'un zelda c'est qu'on traverse les salles une à une en "scrollant" donc a chaque "scroll" (ou changement d'écran si vous préférez), la classe zoneDonjon est détruite puis recréée avec les nouvelles infos de la zone.

Mais il y a des portes à clés dans un donjon avec des clés. Ce sont des objets spécifiques aux donjons qui n'existent pas dans les autres type de monde.

Question : Où gérer les clés et l'ouverture des portes à clé ?

Actuellement, les clés sont gérés dans Donjon et l'ouverture des portes à clé dans zoneDonjon puisque une porte à clé fait partie d'une zone (ou salle).

Heuuu... ne crois tu pas que tant l'ouverture des portes que la gestion des clés devrait échoir à tes objet de type Monde (ou dérivé)

Au pire, ta zone doit simplement savoir:

combien de clés il y avait à trouver
combien de clés ont été trouvées
combien de clés ont été utilisées

et ce sont trois informations que le monde ne doit, à l'extrême limite, pas retenir: il n'a "qu'à" transmettre le fait qu'une clé est trouvée / utilisée à la zone qui s'occupe de sa gestion

**koala01** · 19/11/2010, 12h49

La partie portant sur le débat pour ou contre l'amitié a donné lieu à la scission de cette discussion.

Vous pouvez vous exprimer sur le sujet à cette adresse.

Merci de votre compréhension

**Astraya** · 19/11/2010, 13h00

Sinon il faut penser que l'héritage n'est pas toujours un cas utile

des fois, l'agrégation est utiles. Avec des templates et c'est top! En plus tu économise le coup du polymorphisme

J'aurais vu un truc comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
template<typename Zone>
class typeMonde
{
     protected:
     Zone* salle;
};
 
 class ZoneDonjon
{
     // ...
};

class Donjon : public typeMonde<ZoneDonjon>
{
     private:
     int nbCle;
};

Nan?

PS: Elle déconne cette balise code avec les copier coller.

**Emmanuel Deloget** · 19/11/2010, 13h34

Envoyé par Astraya

Sinon il faut penser que l'héritage n'est pas toujours un cas utile

des fois, l'agrégation est utiles. Avec des templates et c'est top! En plus tu économise le coup du polymorphisme

J'aurais vu un truc comme ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
template<typename Zone>
class typeMonde
{
     protected:
     Zone* salle;
};
 
 class ZoneDonjon
{
     // ...
};

class Donjon : public typeMonde<ZoneDonjon>
{
     private:
     int nbCle;
};

Nan?

PS: Elle déconne cette balise code avec les copier coller.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
class Donjon : public typeMonde<int>
{
}

Ou, pour une discussion plus générale sur ce sujet particulier.

**Astraya** · 19/11/2010, 13h42

Je suis d'accord avec l'article. Je faisais une proposition, je ne connais rien de l'architecture du jeu. Mais il est clair que ici l'héritage comme présenté n'est pas la solution à apporter.

C'est là que je me dis que le GOCS est bien

**Aspic** · 19/11/2010, 13h45

Ouah je sens que ce WE je vais potasser vos différentes solutions ^^
Alors pour le friend, j'irais regardé ce soir le débat pour me faire une idée car je connais mal ce concept.

Je voulais savoir pourquoi l'utilisation de variables statiques est une erreur ? (j'aime bien comprendre mes erreurs

)

@Astraya : ta méthode avec les templates, tu pourrais en dire plus ? En quoi, elle permettrait de résoudre mon problème ?

**koala01** · 19/11/2010, 14h39

Envoyé par Aspic

Je voulais savoir pourquoi l'utilisation de variables statiques est une erreur ? (j'aime bien comprendre mes erreurs

)

Simplement parce qu'une variable statique est une variable qui existe même s'il n'existe aucune instance de la classe, mais qui est également utilisée par l'ensemble des instances existantes s'il y en a.

Pour faire simple, c'est une variable globale déguisée par le fait qu'elle se rapporte à un type bien précis (la classe dans laquelle elle est déclarée).

Si tu y rajoute des accesseurs (getters) et des mutateurs (setters), cela revient, de toutes manières, à autoriser n'importe qui à aller consulter ou modifier les valeurs.

J'explique dans le débat sur l'amitié pourquoi c'est une mauvaise idée, je ne vais donc pas le répéter ici, mais cela revient à peu de choses près au même que si ces variables statiques étaient carrément publiques

.

Mais le principal problème est, surtout, que les variables statiques sont "partagées" entre les différentes instances de ta classe.

Cela signifie que si tu as trois instances différentes de ta classe et que tu décide d'aller modifier la variable (à l'aide du mutateur, sans doute), les trois instances utiliseront exactement la même valeur

Cela implique, si tu te dis "je vais charger plusieurs zones en même temps de manière a avoir un peu d'avance et d'assurer plus de fluidité au jeu" et que chacune des zones dispose d'un certain nombre de clé:

que le nombre de clé dont chaque zone disposera une fois le chargement terminé sera celui... de la dernière zone chargée (ce qui ne correspond pas forcément au nombre de clés dont dispose la première qui sera visitée )
que, lorsque tu "retirera" une clé, elle sera retirée pour toutes les autres zones, y compris, celles que tu n'a pas encore visité... avec le risque d'atteindre 0 alors qu'il y en a normalement XXX à trouver, et donc de te retrouver bloqué parce que tu ne peux, simplement pas, trouver les clés qui te permettront de sortir

En gros, on peut dire que les variables statiques sont utiles, mais que leur utilisation doit être très murement réfléchie

**Astraya** · 19/11/2010, 15h01

ta méthode avec les templates, tu pourrais en dire plus ? En quoi, elle permettrait de résoudre mon problème ?

Je me suis mélanger un peu les pinceaux. J'ai réaliser un petit programme de test pour illustrer mon propos, c'est plus simple qu'une longue phrase

.
Ne connaissant pas tout de ton programme je ne peux pas affirmer grand chose, si ce n'est que si "ZoneDonjon" veux accéder à son type de monde il dois le connaitre. Donc le paramètre à la construction ou autre méthode.

le template est la plus dans un esprit de protection, Si tu créer un monde de donjon et effrayant "DongonEffrayant" , tu ne peux lui donner que des salles DongonEffrayant. Sa permet de forcer à respecter un certain esprit graphique ou autre au seins du code. Dans un monde de fleur et de lutin, tu ne met pas une station spatial. Par contre c'est facilement contournable avec un static_cast, mais la faut frapper le programmeur qui le fais

En étudiant sur Visual ton code, j'ai cru observer un problème. Ton monde connais les salles mais les salles ne connais pas ton monde. ça devrais être l'inverse ou les deux.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
58
59
60
61
62
63
64
65
66
67
68
#include <iostream>
 
 
class typeMonde
{
 
};
 
//3 types de Monde
class Donjon : public typeMonde
{
private:
    int nbCle;
public:
    Donjon()
        :nbCle(1){}
    int GetCle(){return nbCle;}
};
class DonjonEffrayant : public typeMonde
{
    int nbCleEffrayante;
public:
    DonjonEffrayant()
        :nbCleEffrayante(2){}
    int GetCle(){return nbCleEffrayante;}
};
class DonjonLabyrinthe : public typeMonde
{
    int nbCleLabyrinthique;
public:
    DonjonLabyrinthe()
        :nbCleLabyrinthique(3){}
    int GetCle(){return nbCleLabyrinthique;}
};
 
//Une zone pouvant appartenir à différent type de monde.
class Zone
{
 // ....
};
 
template < typename monde>
class ZoneDonjon : public Zone
{
    monde * dongeon_;
public:
 
    ZoneDonjon( monde * dongeon)
        :dongeon_(dongeon)
    {
        std::cout << dongeon_->GetCle() << std::endl;
    }
    // ...
};
 
 
int main()
{
    typeMonde* tm = new Donjon();
    typeMonde* tm1 = new DonjonEffrayant();
    typeMonde* tm2 = new DonjonLabyrinthe();
    Zone* newZone = new ZoneDonjon<DonjonEffrayant>(static_cast<DonjonEffrayant*>(tm1));
    Zone* newZone1 = new ZoneDonjon<Donjon>(static_cast<Donjon*>(tm));
    Zone* newZone2 = new ZoneDonjon<DonjonLabyrinthe>(static_cast<DonjonLabyrinthe*>(tm2));
    system("pause");
//delete de tout
return 0;
}

**Aspic** · 19/11/2010, 18h27

Ton code fonctionne mais ce qui m'embête c'est l'utilisation de static_cast, c'est pas très bien vue...

Après j'ai tellement de solution proposées que je ne sais pas quoi choisir

Je vais aller voir la discussion sur l'amitié pour voir si ca corrige mon problème, de ce fait ca m'évitera de recoder toutes la structure des mondes et zones.

**Astraya** · 19/11/2010, 18h58

Ton code fonctionne mais ce qui m'embête c'est l'utilisation de static_cast, c'est pas très bien vue...

static_cast n'est pas mal vue. C'est un cast à la compilation. Il n'apporte aucun coût à l'exécution.

**Aspic** · 19/11/2010, 19h06

Envoyé par Astraya

static_cast n'est pas mal vue. C'est un cast à la compilation. Il n'apporte aucun coût à l'exécution.

Autemps pour moi

alors c'est le dynamique_cast qui est le Mal

**Astraya** · 19/11/2010, 19h08

A la compilation: static_cast, const_cast.
Au runtime : dynamic_cast , reinterpret_cast.

**3DArchi** · 20/11/2010, 09h28

Envoyé par Aspic

Autemps pour moi

alors c'est le dynamique_cast qui est le Mal

L'utilisation static_cast ou dynamic_cast n'est pas 'mal' en soit. C'est le downcast depuis la classe de base vers la classe dérivée qui est souvent source de méfiance. Ce downcast peut être à l'exécution (dynamic_cast) ou la compilation (static_cast). La downcast vers la classe dérivée aboutit souvent à briser le LSP et par ricochet briser le OCP. D'où cette méfiance. Conclusion static_cast ou dynamic_cast doivent éveiller une méfiance similaire.

Envoyé par Astraya

A la compilation: static_cast, const_cast.
Au runtime : dynamic_cast , reinterpret_cast.

C'est nouveau l'évaluation de reinterpret_cast au runtime

Ici, c'est vrai que l'héritage semble plus adéquat que l'approche générique. Il me semble que la solution d'Emmanuel pouvait répondre à ta question.