[C++] Héritages et classes

Version imprimable

Bonsoir,

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

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 :mouarf:

Merci

18/11/2010, 22h39
Eusebius

Citation:

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.
18/11/2010, 22h58
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 ?
19/11/2010, 08h45
Eusebius

Citation:

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.
19/11/2010, 09h53
AF_2.8

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.
19/11/2010, 12h14
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 :D, 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

Citation:
Envoyé par Aspic
Bonsoir,

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

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 :mouarf:

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:

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.

19/11/2010, 12h38
koala01
Citation:

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 :D, 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 :question:

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 :D

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é :D (bon, j'exagère un peu, mais je suis quand même pas loin de la vérité :D)

Citation:

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 ;)

Citation:

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 ;)

Citation:

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é) :question:

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 ;)
19/11/2010, 12h49
koala01

Avis de scission

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

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 :ccool:

J'aurais vu un truc comme ça:
Code:

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?:mrgreen:

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

Citation:
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 :ccool:

J'aurais vu un truc comme ça:
Code:

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?:mrgreen:

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

1 2 3 class Donjon : public typeMonde<int> { }
Ou, pour une discussion plus générale sur ce sujet particulier.

19/11/2010, 13h42
Astraya

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 :ccool:
19/11/2010, 13h45
Aspic

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 :aie:)

@Astraya : ta méthode avec les templates, tu pourrais en dire plus ? En quoi, elle permettrait de résoudre mon problème ?
19/11/2010, 14h39
koala01
Citation:

Envoyé par Aspic

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

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 :P;).

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 :aie:

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 :aie:)
- 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 :aie:
En gros, on peut dire que les variables statiques sont utiles, mais que leur utilisation doit être très murement réfléchie ;)

Citation:

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 :aie:.
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 :aie:

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:

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; }

19/11/2010, 18h27
Aspic

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 :D
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.
19/11/2010, 18h58
Astraya

Citation:

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.
19/11/2010, 19h06
Aspic

Citation:

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 :D
19/11/2010, 19h08
Astraya

A la compilation: static_cast, const_cast.
Au runtime : dynamic_cast , reinterpret_cast.
20/11/2010, 09h28
3DArchi

Citation:

Envoyé par Aspic

Autemps pour moi :)
alors c'est le dynamique_cast qui est le Mal :D

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.

Citation:

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 8O

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.
20/11/2010, 11h02
Emmanuel Deloget

Citation:

Envoyé par Astraya

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.

Ah non :) Je m'inscrit en méchant designer qui contre ce que tu dis ! :)

Puisque le monde a l'obligation de connaitre les salles (parce que les salles sont dans le monde; le monde a besoin d'une liste de salles, sans quoi personne ne sait ou sont les salles), cela veut dire que les salles ont l'interdiction de connaître le monde. Dans le cas contraire, on a une référence circulaire, ce qui

1) introduit un couplage fort là ou il n'y en a pas besoin
2) viole certains des principes de conception orientée objet (longue discussion à prévoir sur ce point, donc je ne vais pas entrer dans les détails maintenant).
20/11/2010, 11h59
Astraya

Citation:

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

Étant donné que à la compilation il ferme les yeux sur le cast, les problèmes ne seront visible que à l'exécution. Ne l'utilisant jamais, je ne sais pas si il prend du temps à l'éxecution mais ce qui est sur c'est que aucune validation du compilateur ne sera faite sur ce cast. C'est à ça que je pense que je dis au "Runtime".

Citation:

introduit un couplage fort là ou il n'y en a pas besoin

Oui je suis d'accord, dans le code que j'ai donné, il n'y a pas de couplage fort. Juste le contenu connais le conteneur et pas l'inverse (j'ai un raisonnement à l'inverse de l'habitude il est vrai :aie:). Dans ta solution que je trouve aussi meilleur tu donnes des informations mais pas la classe. C'est une manière un peu caché de masqué le couplage, mais il y en a un en réalité sous une autre forme plus perverse. Je donne la classe, tu donnes les informations de la classe.
20/11/2010, 12h12
koala01

Citation:

Envoyé par Emmanuel Deloget

2) viole certains des principes de conception orientée objet (longue discussion à prévoir sur ce point, donc je ne vais pas entrer dans les détails maintenant).

N'hésite cependant pas, si tu en as le temps/ l'envie / le courage ;)

Nous scinderons la discussion en cas de besoin :D
20/11/2010, 12h21
Emmanuel Deloget

Citation:

Envoyé par Astraya

Oui je suis d'accord, dans le code que j'ai donné, il n'y a pas de couplage fort. Juste le contenu connais le conteneur et pas l'inverse (j'ai un raisonnement à l'inverse de l'habitude il est vrai :aie:). Dans ta solution que je trouve aussi meilleur tu donnes des informations mais pas la classe. C'est une manière un peu caché de masqué le couplage, mais il y en a un en réalité sous une autre forme plus perverse. Je donne la classe, tu donnes les informations de la classe.

Je vais même aller plus loin que toi : c'est un couplage aussi. Mais de là à dire qu'il est plus pervers, il y a un pas que je ne sauterais pas :)

(edit: entre le post de mon message et l'edit, un autre post a été rajouté. Donc je déplace l'édit dans un nouveau post, histoire que tout ça soit plus clair)
20/11/2010, 12h26
Astraya

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche :roll:
20/11/2010, 12h32
Emmanuel Deloget
Citation:

Envoyé par koala01

N'hésite cependant pas, si tu en as le temps/ l'envie / le courage ;)

Nous scinderons la discussion en cas de besoin :D

Temps et courage me manquent aujourd'hui. On verra peut-être demain, mais je doute d'y arriver.

Pour information, j'ai déjà traité courtement d'un type de dépendance circulaire dans cet article, et j'ai aussi un peu bafouiller dessus dans cet autre article, que je me permet de citer, avec l'accord de l'auteur (il a été très sympa avec moi) :
Citation:
Qu'est-ce qu'une dépendance circulaire ?

Bien évidemment, je pose la question alors que je sais que vous connaissez la réponse. Une dépendance circulaire existe à partir du moment ou une classe A dépends d'elle même de manière indirecte, par opposition à une dépendance directe qui (en termes de design) n'est pas dommageable. Cela signifie que A dépends d'une classe B qui elle même dépends de A.

La conséquence logique est que A et B sont fortement couplées. Ce couplage a un impact non désirable sur à la fois le code et l'architecture.

Sur l'architecture, ce fort couplage implique que A et B sont nécessairement utilisées ensemble ; ni l'une ni l'autre n'est réutilisable sans l'autre. Si A dépends aussi de plusieurs classes A1, ..., An, alors l'utilisation de B dans un projet nécessite la connaissance de A, A1, ..., An - ce qui n'a pas vraiment de sens. L'architecture est fortement complexifiée du fait même de ce couplage fort.
Sur le code, une modification dans l'un des deux classes a de grandes chances d'impliquer une modification dans l'autre classe - de manière plus formelle, A est une responsabilité de B qui est une responsabilité de A. En vertu du principe de responsabilité unique, cela signifie que ni A ni B ne peuvent avoir d'autre responsabilité ; conceptuellement, on voit bien qu'il y a un problème, parce que ça voudrait dire que ni A ni B ne font quoi que ce soit.

Certaines personnes semblent penser que dès lors que deux classes présentent une forte cohésion (c'est à dire qu'elles traitent de sujets très similaires et qu'il y a de fortes chances qu'elles soient utilisées dans le même cadre applicatif) alors le fait qu'elles soient en plus fortement couplées n'a pas véritablement d'incidence sur la qualité du design ou sur le code. Ce n'est pas vrai, pour une simple et bonne raison : tôt ou tard, un couplage fort entraine l'utilisation dans un module de dépendances qui n'ont pas de lien de cohésion avec les autres parties du module. La cohésion globale est donc réduite d'autant. A terme, plus le couplage est fort, plus la cohésion du module sera faible. Seul un couplage faible permet de s'assurer d'une forte cohésion entre les différentes classes d'un module.

Citation:

Envoyé par Astraya

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche :roll:

On peut rajouter une classe (voire, une hiérarchie)
Code:

1 2 3 4 5 6 7 8 9 A <|-- B ^ | transmet les ordres à | |<|-- F ? (F éventuel hérite de E) E--|<|- -G ? (G éventuel hérite de E) ^ |<|-- H ? (H éventuel hérite de E) | ordone à | C <|-- D
où E est un médiateur connaissant l'ensemble des objet dérivés de A ;)

20/11/2010, 12h35
Emmanuel Deloget
Citation:

Envoyé par Astraya

Maintenant on est d'accord pour dire que si on a un schéma comme présenté ici :

A <|-- B ( B hérite de A )
C <|-- D ( D hérite de C )

Si on veux faire communiquer B et D directement sans passé par leur abstraction A et C. Nous n'avons pas le choix de créer un couplage entre les deux. A moins que l'un d'entre vous aurais une solution à apporter pour l'éviter en essayant de conservé un maximum le schéma initiale. La je sèche :roll:

Tout ceci est exact - tu dois coupler B et D. Cependant, lorsque conceptuellement tu as
Code:

1 2 3 4 5 A <|-- B * | C <|-- D
(A possède des instances de C; pas de losange, désolé)

Alors tu complète avec
Code:

1 2 3 4 5 A <|-- B * * | | C <|-- D
Edit: dans le cas de l'OP, Monde connait Zone, et il n'est pas abhérant que MondeDonjon connaisse ZoneDonjon.
20/11/2010, 12h41
Astraya
Très bien très bien.
Mais peut-on voir en soit une faiblesse dans le design si l'on ce retrouve avec ton dernier schéma?
Code:

1 2 3 4 5 A <|-- B * * | | C <|-- D
J'aurais tendance à dire en voyant ça que le code deviendra vite problématique en complexité dans un projet de taille imposante comme un jeu, et qu'il faudrait imaginer une autre solution utilisant la composition plutôt que l'héritage.
20/11/2010, 12h52
Emmanuel Deloget
Citation:
Envoyé par Astraya

Très bien très bien.
Mais peut-on voir en soit une faiblesse dans le design si l'on ce retrouve avec ton dernier schéma?

Code:

1 2 3 4 5 A <|-- B * * | | C <|-- D

J'aurais tendance à dire en voyant ça que le code deviendra vite problématique en complexité dans un projet de taille imposante comme un jeu, et qu'il faudrait imaginer une autre solution utilisant la composition plutôt que l'héritage.
Ce pattern dont je ne retrouve plus le nom se trouve partout. B spécialise A, donc il est logique que D spécialise C. Dans un jeu ou il y a 36 types de mondes possibles et 400 types de salle possible, le design sur tu proposes nécessite de mettre les caractéristiques utiles à chaque salle dans la classe mère Monde - qui se transforme donc en God Class avec une cohésion très faible - de manière à ce que les 400 classes de salles puisse obtenir les informations qu'elles souhaitent. Dans mon cas, les interfaces des classes la classe mère monde dépends uniquement des fonctionnalités qu'on souhaite y implémenter (getZone, ...). Chaque type de monde est responsable pour initialiser correctement les salles qu'il contient. Et vogue la galère.

Je suis prêt à parier que cette approche est plus maintenable que celle que tu propose :)
20/11/2010, 13h02
Astraya

Citation:

Je suis prêt à parier que cette approche est plus maintenable que celle que tu propose :)

Sans aucun doute :mouarf:. Je préfère souvent privilégier la composition à l'héritage et ce ramené à un système de composant. Un TypeDeMonde est composé d'une parti commune (Monde) et d'un parti personnel (ZoneDonjon). Je me rapproche toujours un maximum du principe des Game Object Component. C'est peut-être un défaut, ce n'est pas facile à faire adopter à tout le monde mais c'est bien pratique. Il y a d'ailleurs des présentations à certain GDC la dessus, certains aime d'autre moins.
Les anciens ont leurs petites habitudes bien ancrées je dirais :aie:

Edit: Je viens rajouter quelques liens sur des PDF du GDC 2009 et 2010. L'un sur une architecture dynamique de composant pour des hautes performances. Et l'autre mettant face à face la programmation orientée objet classique contre la programmation orientée composant.