Discussion :

[Rhaegar()]

Bonjour,

J'ai un problème lié à l'héritage et je ne sais pas comment le résoudre.

J'ai deux classes Goomba et Koopa qui héritent chacune de ma classe Entity. Ma classe Zone contient comme attribut une collection hétérogène d'Entity contenant donc des pointeurs vers des instances de Goomba et de Koopa. J'ai ajouté une méthode changerOrientation() à la classe Koopa qui n'est pas dans Entity et j'aimerais pouvoir l'utiliser depuis ma classe Zone. Je ne vois pas comment faire.

Mon attribut(La collection hétérogène) dans la classe Zone

Code :

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

1
2
 
std::deque<Entity*> m_entites;

La classe Koopa :

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
 
#ifndef KOOPA_H_INCLUDED
#define KOOPA_H_INCLUDED
 
#include "Entity.h"
 
class Koopa : public Entity
{
public:
    Koopa(float x, float y);
    void seDeplacer();//vp
    void sAnimer();//vp
 
    void changerOrientation();
 
private:
    bool m_orientationDroite;//true s'il regarde à droite false sinon
 
};
 
#endif // KOOPA_H_INCLUDED

La fonction dans Zone censée utiliser changerOrientation()

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
 
void Zone::horsZone()
{
    unsigned int t(m_entites.size()), i;
    for(i = 0; i<t; ++i)
    {
        if(m_entites[i]->getPosition().y > m_origine.y + m_hauteur)//si on est en dessous de la zone
        {
            rearanger(i);
        }
        else if(m_entites[i]->getPosition().x < m_origine.x || m_entites[i]->getPosition().x > m_origine.x + m_largeur)//si on est à gauche ou à droite de la zone
        {
            if (typeid(*m_entites[i]) == typeid(Koopa))
            {
                m_entites[i]->changerOrientation();
 
            }
        }
    }
}

[oodini]

Si tu en arrives à coder des choses du genre :

Code :

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

if (typeid(*m_entites[i]) == typeid(Koopa))

c'est que tu as un problème de conception.

La bonne manière de faire est d'ajouter changerOrientation() comme méthode virtuelle à Entity, avec un corps vide. Tu la redéfinis dans Koopa.

Si la présence de cette fonction n'a vraiment aucun sens pour les types autres que Koopa, tu peux créer à la place une autre méthode virtuelle, au nom assez générique ( du genre postProcess()), dont la redéfinition dans Koopa appellera changerOrientation().

[Rhaegar()]

Ok merci je vais mettre la méthode changerOrientation() dans ma classe Entity. Je trouve ça juste dommage et "encombrant" de rajouter une méthode avec un corps vide mais bon s'il n'y a pas d'autres solutions. Merci encore.

Ducoup deuxième problème : Comment faire pour savoir vers quel type pointe mes pointeurs dans m_entites sans utiliser typeid ? Par exemple, si c'est un Goomba, je détruis l'Entity, et si c'est un Koopa, je détruis l'Entity et la remplace par une Carapace (héritant de Entity).

[oodini]

Du coup deuxième problème : Comment faire pour savoir vers quel type pointe mes pointeurs dans m_entites sans utiliser typeid ? Par exemple, si c'est un Goomba, je détruis l'Entity, et si c'est un Koopa, je détruis l'Entity et la remplace par une Carapace (héritant de Entity).

Tu ne devrais pas être amené à te poser cette question. Si c'est le cas, c'est que tu as un problème de conception.

D'après ce que tu exposes,je pense que la première question à se poser est : ce vecteur a-t-il un sens ? Est-il nécessaire ?

[Rhaegar()]

Il a un sens dans le fait que souvent, toutes les Entity seront traitées de la même façon. Par exemple, lorsque je détruis Zone, le destructeur détruit toutes les Entity pointées par m_entites via une seule boucle pour. De même, la méthode animation de Zone va appeler la méthode animation de chaque Entity par une boucle pour.

Cependant, j'ai parfois besoin d'effectuer différentes choses en fonction du type d'Entity(Goomba ou Koopa)

Sinon je pourrais faire différents vecteur pour chaque type d'Entity mais je trouve dans ce cas l'utilisation des collections hétérogènes très limitée.

[koala01]

Salut,

Il a un sens dans le fait que souvent, toutes les Entity seront traitées de la même façon. Par exemple, lorsque je détruis Zone, le destructeur détruit toutes les Entity pointées par m_entites via une seule boucle pour. De même, la méthode animation de Zone va appeler la méthode animation de chaque Entity par une boucle pour.

Cependant, j'ai parfois besoin d'effectuer différentes choses en fonction du type d'Entity(Goomba ou Koopa)

Sinon je pourrais faire différents vecteur pour chaque type d'Entity mais je trouve dans ce cas l'utilisation des collections hétérogènes très limitée.

Ca, j'ai envie de dire que c'est TON point de vue...

Mais ce que oodini tente de t'expliquer, c'est qu'il se peut (et c'est même très probable) que ton problème est sans doute beaucoup plus profond et trouve son origine dans ... le fait de décider que Koopa et que Goomba en viennent à hériter de Entity.

Car l'héritage est la relation la plus forte qui puisse exister entre deux classes car elle représente littéralement le fait que n'importe quelle instance de la classe dérivée peut être considérée comme étant une instance de la classe de base.

Il doit donc respecter des règles strictes qui sont en l'espèce imposées par le LSP.

Je ne vais pas dire (je ne connais pas assez ton projet pour en venir à cette conclusion) que tu as commis une erreur de conception en décidant de faire hériter Goomba ou Koopa de Entity. Il se peut au demeurant que cette décision soit tout à fait sensée et qu'elle respecte intégralement le LSP.

Mais, une chose est sure : si tu as été "assez bête" (même si c'est par nécessité), pour en arriver, à un moment ou à un autre, à considérer que tous tes Goompa et / ou que tous tes Koopa sont des Entity, tu ne peux appeler que les comportements issus de Entity, à l'exclusion de tout autre et tu ne peux surtout pas commencer à entrer dans une logique par laquelle tu essayerais de déterminer si ton entité est un Goompa ou un Koopa avant de la transtyper dans l'un ou dans l'autre afin de pouvoir faire appel aux comportements spécifiques de ce genre de donnée.

Il existe en effet un principe d'or nommé OCP pour Open Close Principle, qui dit qu'un code doit être "ouvert aux évolutions" mais "fermé aux modifications".

Si tu commences à écrire un code qui ressemble peu ou prou à quelque chose comme

Code :

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

1
2
3
4
5
6
7
if(entity->type() == Koopa){
    dynamic_cast<Koopa>(entity)->trucSpecificAKoopa();
}else if(entity->type() == Goompa){
    dynamic_cast<Goompa>(entity)->trucSpecificAGoompa();
} else if(entity->type() == MachinBrol){
    dynamic_cast<MachinBrol>(entity)->trucSpecificAMachinBrol();
}

tu écris du code qui ne respecte pas l'OCP, et le résultat sera sans appel: dans "quelque mois" tu voudra rajouter une classe supplémentaire (mettons Truc) à ta hiérarchie, et, pour que cette classe supplémentaire soit prise en compte, tu devrais modifier tous les endroits du code dans lequel ce genre de logique est mis en oeuvre pour y rajouter les lignes

Code :

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

1
2
3
else if(entity->type()== Truc){
    dynamic_cast<Truc>(entity)->trucSpecificATruc();
}

La loi de finagle aidant, tu penseras à modifier un des endroits en question, peut-être deux, mais tu en oublieras bon nombre d'autres.

Si tu veux trouver une solution correcte à ton problème, les mots clés à rechercher sont virtualité des fonctions et double dispatch.

L'exemple classique de mise en oeuvre du double dispatch que l'on propose régulièrement porte le nom du patron de conception visiteur.

[Rhaegar()]

Salut koala01,

Je te remercie pour ton message très instructif.

Etant débutant, je ne connaissais pas le LSP et l'OCP et mes connaissances en programmation sont limitées. Je réalise maintenant qu'effectivement j'ai du mal concevoir ma classe. Mais je persiste à penser que Koopa et Goomba doivent héritées de Entity du fait de leurs nombreuses méthodes en commun.

Je vais me renseigner et réfléchir à une solution permettant de régler mon problème notamment avec les notions que tu as citées.

Merci encore.

[koala01]

Salut koala01,

Je te remercie pour ton message très instructif.

Etant débutant, je ne connaissais pas le LSP et l'OCP et mes connaissances en programmation sont limitées. Je réalise maintenant qu'effectivement j'ai du mal concevoir ma classe. Mais je persiste à penser que Koopa et Goomba doivent héritées de Entity du fait de leurs nombreuses méthodes en commun.

Je ne dis pas forcément le contraire, mais si, pour une raison ou une autre, tu décide de faire cohabiter des Koopa et des Goomba dans une même collection d'objets (qui serait une collection de Entity pour le coup), tu dois comprendre que tu ne pourra accéder qu'aux fonctions et méthodes connues pour le type Entity.

[bacelar]

Si le terme "Entité" est lié au concept de "ECS", il faut bien faire attention que l'approche "tout objet" se marie assez mal avec "ECS".
Dans un ECS, Entité n'est qu'un simple "ID" où les "composants" se greffent.

Je trouve que vous évacuez assez rapidement la 2ème proposition de @oodini, sur l'usage méthodes virtuelles "génériques" comme "postProcess".
En mettant un place un pipeline des systèmes, par exemple:
- calcul IA
- calcul Physique
- prise en compte entré réseau/périphérique
- calcul animation
- calcul rendering
Vous pouvez avoir l'appel d'une méthode virtuelle de Entity entre chaque étape du pipeline, permettant de mettre en branle chaque système; qui mettra en œuvres les composants qui l'intéresse.

Comme le dit @koala01, l'héritage est si puissant qu'il ne doit être que le "dernier recours". Quand l'héritage à vraiment un sens, et pas juste de la factorisation de code.
Si les Koopa et les Goomba partagent des comportements, ils devraient partager des composants, pas un ancêtres commun.

[Rhaegar()]

Entity n'est pas liée au concept d'ECS, que je connaissais pas mais qui à l'air intéressant. Mon programme est fait en POO.

Lorsque j'appelle la méthode Zone::Cliquer(), une Entity va être détruite via un delete. Cependant, si l'Entity est un Koopa, l'Entity va également être détruite mais en plus, une autre Entity(de type dynamique Carapace) va être créée par un new.
Au final, j'ai fait une méthode virtuelle dans Entity qui me renvoi un pointeur vers une Entity. Le corps de la méthode contient seulement un return 0; Je redéfinis cette méthode dans la classe Koopa. Le corps de la méthode contient cette fois l'allocation dynamique d'une Carapace dans un pointeur qui sera retourné.
Avant la destruction d'une Entity dans la classe Zone, la méthode va être appelée et le pointeur retourner va être stocker dans un pointeur p. Je delete le Koopa, et j'affecte p à la case du vecteur qui pointait sur le Koopa.

Au final, ça marche cependant ça ne respecte pas l'OCP. Si un jour je veut faire une nouvelle classe héritant de Entity et qui, à la destruction d'une des instances de cette classe créer deux nouvelles Entity, je devrai modifier mon code. Aussi, si je veux faire en sorte que cette même classe, lorsque elle est détruite, détruise à son tour toutes les Entity du vecteur m_entites de Zone, je ne peux pas.

En fait j'aimerais pouvoir accéder à m_entites depuis une de mes classe d'Entity mais je ne penses pas que c'est possible.

Si mon programme est mal conçut, ce qui est surement le cas, je ne sais pas comment le concevoir d'un point de vu POO.

Question autre : Est-ce qu'on peut faire un delete this dans une méthode. Et qu'est ce qu'il se passe au niveau du compilateur si on le fait ?

[Bousk]

Sinon, tu as déjà une fonction particulière spécifique à chaque élement que l'on appelle destructeur.
Ton destructeur peut très bien créer 1, 2 ou 14 objets et les enregistre dans la structure qui se charge de les garder en vie et mettre à jour/afficher.
De toute évidence tu as un problème de conception, et des lacunes de code et design. Et mettre POO et ECS en opposition, mué bof. L'ECS utilise complètement, et intelligement, les principes de la POO donc bon..
De ton Entity (qui est un terme 25 fois trop vague), tu devrais avoir un truc plus concret tel que Enemy, ou Character, qui a une méthode onDeath. Que le Koopa, qui est un Character, crée une carapace à sa mort, le Goomba qui ne fait rien de particulier ça lui en touche une sans bouger l'autre. Et onDeath gagnerait à avoir une implémentation par défaut qui ne fait... rien.

[bacelar]

Sinon, tu as déjà une fonction particulière spécifique à chaque élement que l'on appelle destructeur.

Sauf que le destructeur, c'est juste pour la gestion de la mémoire, pas pour implémenter des règles business de transmutation ou de création de sous-produits "debris".
Donc, la méthode "onDeath" est bien plus pertinente, je trouve.

Ton destructeur peut très bien créer 1, 2 ou 14 objets et les enregistre dans la structure qui se charge de les garder en vie et mettre à jour/afficher.

Cela génèrerais des dépendances de malade entre les différentes classes.
Donc, la méthode "onDeath" est bien plus pertinente, je trouve.(BIS)

Et mettre POO et ECS en opposition, mué bof. L'ECS utilise complètement, et intelligement, les principes de la POO donc bon..

Clairement, quand on fait un ECS, ce qui compte avant tout, c'est la flexibilité des entités et la mise en place de pipeline pour les systèmes.
L'aspect POO passe largement après.
Il faut tordre l'approche objet traditionnel pour avoir un ECS convenable.

De ton Entity (qui est un terme 25 fois trop vague)

Pas dans un ECS car ce n'est qu'un identifiant et absolument rien d'autre.

tu devrais avoir un truc plus concret tel que Enemy, ou Character

Dans un ECS, c'est des composants, pas des classes.

qui a une méthode onDeath.

En approche objet, c'est pas mal.

Moi, je vous conseille d'avoir une méthode "onDeath" qui renverrait un std::vector<Entity> correspondant en Entité de remplacement de l"object mourant.
S'il y a "tansmutation", ce std::vector<Entity> contiendra un élément, s'il y a destruction définitive le std::vector<Entity> contiendra 0 élément, s'il explose en plein de sous-élément std::vector<Entity> contiendra tout plein d'éléments.

Et onDeath gagnerait à avoir une implémentation par défaut qui ne fait... rien.

Plutôt qui renverrait un std::vector<Entity> avec 0 élément.

La classe en charge de maintenir la liste des entités, enlèvera l'objet touché de la liste des entités, appelera "onDeath" sue cet objet, et ajouta les Entité retourné par "onDeath" dans la liste des entités, et c'est dans la boite.

Lorsque j'appelle la méthode Zone::Cliquer(), une Entity va être détruite via un delete.

Nope, cf. ma phrase du dessus.
Retrait de l'entité de la liste des Entités, puis appel à son "onDeath", ajout des éléments renvoués dans la liste des Entités, puis suppression de l'entité touché avec la primitive la plus adaptée.

va être créée par un new.

Éviter la gestion manuelle de la mémoire, donc pas de new. A la rigueur, utilisez des pointeurs intelligent.

une méthode virtuelle dans Entity qui me renvoi un pointeur vers une Entity

Non, pas un pointeur moisi, un std::vector<Entity>.

Le corps de la méthode contient seulement un return 0;

Non, 0 n'est pas un pointeur valide, et NULL ne l'ai plus. Utiliser "nullptr" s'il le faut.

Le corps de la méthode contient cette fois l'allocation dynamique d'une Carapace dans un pointeur qui sera retourné.

Éviter la gestion manuelle de la mémoire, donc pas de new. A la rigueur, utilisez des pointeurs intelligent.(BIS)

En fait j'aimerais pouvoir accéder à m_entites depuis une de mes classe d'Entity mais je ne penses pas que c'est possible.

Si c'est possible, mais cela ferait un couplage fort complètement contre-productif.

Laissez le code qui gère l'ensemble des entités faire son travail.

Si mon programme est mal conçut, ce qui est surement le cas, je ne sais pas comment le concevoir d'un point de vu POO.

Faire simple.

Question autre : Est-ce qu'on peut faire un delete this dans une méthode. Et qu'est ce qu'il se passe au niveau du compilateur si on le fait ?

C'est totalement "légal" mais vous serez dans la moïse.
delete ne fait qu'appeler le destructeur de l'objet puis la C-Runtime pour lui dire que la zone mémoire est libre pour un autre usage ultérieur.
Donc le contenu n'est pas forcement écrasé tout de suite => bugs bien relou à analyser.

Pour le compilateur, c'est juste un appel de méthode comme un autre.
C'est la C-Runtime qui, à l'exécution, fera ce qui l'arrange.

[Rhaegar()]

J'ai fais la méthode onDeath() qui renvoie un vector<Entity*> et ça marche nickel.
J'ai pas réussi à utiliser nullptr.
Je ne connais pas les pointeurs intelligents, je me renseignerai plus tard. Donc pour l'instant, pointeur normal.

Je pense que mon programme va avoir besoin d'une version 2.0 où je vais plus réfléchir à la conception parce que là c'est plus possible.

Et au passage, si vous connaissez des bouquins pour apprendre des notions c++, ou comment bien concevoir ses programmes je suis preneur. Pas d'un niveau trop avancé parce que je débute.

Voilà merci

[koala01]

J'ai fais la méthode onDeath() qui renvoie un vector<Entity*> et ça marche nickel.
J'ai pas réussi à utiliser nullptr.
Je ne connais pas les pointeurs intelligents, je me renseignerai plus tard. Donc pour l'instant, pointeur normal.

Je pense que mon programme va avoir besoin d'une version 2.0 où je vais plus réfléchir à la conception parce que là c'est plus possible.

Et au passage, si vous connaissez des bouquins pour apprendre des notions c++, ou comment bien concevoir ses programmes je suis preneur. Pas d'un niveau trop avancé parce que je débute.

Voilà merci

NOOOONNNNN!!!!

Renseigne toi MAINTENANT sur les pointeurs intelligents, car ils te permettront de faire du code bien plus robuste avec beaucoup moins d'efforts, si bien qu'ils changeront ta vie.

Il faut comprendre que faire un code robuste en ayant recours à l'allocation dynamique de la mémoire, même les experts s'y cassent la gueule, car il y a toujours le problème qu'une exception peut être lancée à un moment où l'on ne s'y attend pas du tout.

A titre d'exemple: Pourrais tu me dire où est le risque de fuite de mémoire dans un code aussi simple que

Code :

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

1
2
3
4
int main(){
    std::vector<int *> tab;
    tab.push_back(new int(8));
}

C'est pour ce genre de raison que la notion de pointeurs intelligents existe depuis plus de quinze ans dans les bibliothèques d'IHM ou dans des bibliothèques comme boost. Ceux qui sont apparus avec C++11 ne sont au final que la prise en compte d'un problème vieux comme le monde! Si bien que, à l'heure actuelle, même un débutant (je voudrais presque dire : surtout un débutant) devrait faire ses premiers pas en abordant en priorité ces notions de pointeurs intelligents, et ne s'intéresser aux cas des pointeurs bruts que s'il se trouve confronté à du code qui date de Mathuzalem

[oodini]

à l'heure actuelle, même un débutant (je voudrais presque dire : surtout un débutant) devrait faire ses premiers pas en abordant en priorité ces notions de pointeurs intelligents, et ne s'intéresser aux cas des pointeurs bruts que s'il se trouve confronté à du code qui date de Mathuzalem

Je travaille à l'heure actuelle sur une énorme base de code où un "débutant" (du moins je l'espère) a mis des shared_ptr partout lorsqu'il a fait un portage à partir de C#, même quand il n'y avait pas besoin d'allocation dynamique. C'est l'enfer.

[koala01]

En termes de fiabilité, je préfères (et de loin) quelqu'un qui utilise des shared_ptr partout, y compris quand l'allocation dynamique de la mémoire n'est pas nécessaire, qu'un débutant qui utilise l'allocation dynamique de mémoire partout avec des pointeurs bruts

Maintenant, il est vrai que j'utilise unique_ptr par défaut et non shared_ptr, mais ca, c'est un autre problème.

Et, bien sur, cette personne a loupé une information capitale : on n'utilise l'allocation dynamique de la mémoire que quand c'est absolument nécessaire

A décharge de cette personne, je penserais volontiers qu'il s'agit d'un très bon développeur venu avec ses habitudes en C# qui n'y connait pas grand chose en C++ si ce n'est que les pointeurs bruts, c'est une source de problèmes sans nom

[Médinoc]

Ça me rappelle une présentation de Bjarne Stroustrup, ça, le fait d'utiliser des pointeurs -- intelligents ou non -- là où une variable locale suffit.

[oodini]

Ça me rappelle une présentation de Bjarne Stroustrup, ça, le fait d'utiliser des pointeurs -- intelligents ou non -- là où une variable locale suffit.

Pourrais-tu donner le lien en clair (les liens vidéos ne sont pas consultables au boulot...) histoire que je l'envoie aux collègues ? Merci.

[Médinoc]

Tu veux dire l'adresse exacte de la vidéo sur Youtube ( https://www.youtube.com/watch?v=2egL4y_VpYg#t=57m13s ), ou des screenshots des slides en question? (sans le commentaire audio, ça n'ira pas loin...)

[oodini]

Tu veux dire l'adresse exacte de la vidéo sur Youtube ( https://www.youtube.com/watch?v=2egL4y_VpYg#t=57m13s ), ou des screenshots des slides en question? (sans le commentaire audio, ça n'ira pas loin...)

Les slides seraient également utiles : consultables au boulot, et ça donnera envie de regarder la vidéo à domicile...