Discussion :

[SebastienM]

Bonjour,

Je souhaite réécrire un petit moteur 3D (que j'avais fait sans notion objet il y a longtemps).
L'idée est de décomposer en plusieurs classes :
-> Engine
----> Scene
---------> Object

par exemple.

Pour cela ma classe scène hérite de Engine - et évidement la classe engine peut avoir plusieurs scènes (logique me direz vous).

Mon soucis est le suivant :
Je veux que dans le code principal, j'instancie un Engine avec certaines propriétés. Jusque là tout va bien.
Ensuite je veux créer une scène - j'instancie donc une scène avec certaines propriétés.
Maintneant, j'aimerai que lorsque j'accède aux propriétés parentes de mon objet scène, je retrouve les propriétés de Engine définies précédemment.

Comment faire ?

Merci.

[r0d]

Bonjour,

tout d'abord, pourquoi la scene hérite de engine? Quelles en sont les raisons objectives?

[SebastienM]

ça me paraît logique ... mais c'est la seule raison que je vois ^^
Il serait plus simple à expliquer en prenant un level en dessous :
Un objet hérite des propriétés d'une scène.

[r0d]

En fait, je ne vois pas de raison qui légitime ce choix. Je dis bien "je ne vois pas", ce qui signifie que peut-être il en existe mais que je passe à côté.

Il y a plusieurs façon d'utiliser l'héritage. Généralement, on l'utilise de façon à retranscrire une relation logique entre deux entités. Par exemple "est un": chien et chat héritent de animal car chien "est un" animal, et chat "est un" animal. Ici, ce n'est pas le cas: une scene n'est pas un moteur.

Il y a aussi l'héritage de type "contrat", très utilisé en java, mais aussi un peu en c++. Cela consiste à définir une interface; interface dans le sens: "un ensemble de fonctionnalités et propriétés". Les classes dérivant d'une interface devront implémenter ces fonctionnalités et propriétés. D'où la notion de contrat: "je suis d'accord pour que tu hérites de moi, mais il faut que tu implémentes ces choses-là". Par exemple, si l'interface animal déclare les fonctions manger(), et que les classes chien et chat veulent hériter de animal, alors il faudra que chien et chat implémentent la fonction manger(). Ici encore, je ne vois pas quel type de contrat il pourrait y avoir entre engine et scene.

Je travaille moi-même, sur mon temps libre, sur un petit jeu video. C'est en 2D, donc c'est différent. Mais j'ai le même type d'architecture, c'est à dire un moteur de rendu, et des scenes. Faire hériter scene de engine (dans mon cas les noms de classes sont différents) ne m'est jamais venu à l'esprit.

A vrai dire, je ne vois pas ce que scene et engine peuvent avoir en commun.
Encore une fois, peut-être que je raconte n'importe quoi parce que je suis passé à côté de quelque chose.
Mais quoi qu'il en soit, lorsqu'on décide d'une relation d'héritage entre deux classes, il faut savoir pourquoi on le fait, sinon c'est qu'il y a quelque chose qui cloche.

[SebastienM]

D'accord, je comprend bien ta réponse, et je te remercie d'avoir pris le temps de me répondre.
En fait je vais essayer de formuler ma question un peu différement ; je cherche un modèle qui pourrait structurer mon code correctement.

J'ai par exemple dans ma classe Engine une gestion des logs - et j'aimerai pouvoir en "profiter" dans mes autres classes (ça peut être des logs ou n'importe quoi).
Ma première idée était de créer un pointeur au sein de mes sous classe permettant de récupérer l'objet engine instancié.

En gros je suis ouvert à toute proposition

[screetch]

que chaque objet connaisse l'engine est une idée qui semble correcte mais qui en fait est dangereuse.

Disons pour simplifier qu'il y a plusieurs types de relations entre objet, qui s'ecrivent en francais avec les 3 verbes:
être
avoir
utiliser

être -> héritage
avoir -> composition
utiliser -> outil, paramètre, méthode

par exemple, le chien est un animal
le chien a un propriétaire
le proprietaire a des chiens
le propriétaire utilise une laisse pour promener le chien


on a donc:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
class Proprietaire
{
  std::vector<Chien*> mesChiens; // a des chiens
  public:
    void promenerChiens(Laisse* laisse); // utilise une laisse, voire même plusieurs
};
 
class Chien : public Animal // est un animal
{
  Proprietaire* proprio; // a un proprietaire
}

Dans ton cas, un Moteur a une scene (par exemple) voire même des scenes
une scene a des objets
les objets utilisent le log (qui, by the way, n'a rien a faire dans la classe Moteur)

[SebastienM]

Bien sûr pour les logs
Voici ma classe "en l'état", c'est à dire un début du début

par contre je n'ai pas compris à quel moment c'est dangereux ?

[screetch]

ton moteur a deux responsabilites: la gestion de la fenêtre/OpenGL/tout ce bordel, et la gestion du log. Deja ca c'est moyennement dangereux.

De plus, si chaque objet connait le moteur, sachant que le moteur connait les objets a la base, tu as une dépendance croisée. Et ca c'est encore pire.
Le mieux serait que les objets n'aient pas besoin de savoir a quel Moteur ils se réfèrent.

[SebastienM]

Ok j'ai compris :
- Je vire la partie log dans une classe à part ; est-il d'ailleurs possible de faire un singletton en c++ ? (j'ai pas cherché sur google donc juste oui ou non )
- Je crée un vecteur permettant à Engine de collecter les scenes.
- Aucune référence à Engine dans les scènes

[screetch]

De préférence.
Le singleton existe et il y a plusieurs implémentations possible, je pense que si tu cherches sur google tu vas avoir pas mal de résultats.

Pour le moteur et les scenes, il y a plusieurs possibilités:
* le moteur "a des" scenes
* le moteur "utilise des" scenes
* la scene "utilise un" moteur

les trois sont approximativement valables mais intuitivement on se que la meilleure solution serait "une scene utilise un moteur" pour être rendue.
Ou bien un objet (que tu n'as pas encore créé) "utilise une scene et un moteur" pour les rendre. ca se traduit par une classe contenant une méthode "dessiner(scene* s, moteur*m)" et qui peut agir sur le moteur en fonction de ce qui est dans la scene.

Ce ne sont que des exemples, il y en a desp lus "simples" que d'autres et des plus "corrects". Les possibilités sont infinies donc c'est a toi de décider
deux conseils: pense bien aux relations entre objets comme décrit ici, ca te permet de savoir qui fait quoi
et une seule responsabilité par classe, de préférence pas trop grosse responsabilité: ton moteur est responsable de la fenetre et du rendu, doit il etre responsable des scenes aussi? en tous cas il ne doit pas etre responsable du log.

[SebastienM]

Ok super je vais réfléchir à tout ça, merci en tout cas !

[r0d]

Juste un dernier mot (je sais je suis lourd ) parce que je pense que c'est important.

Ce que je disais à propos de ton héritage entre scene et engine, c'était en quelque sorte une introduction. Je voulais en arriver, au fil de la discussion, à mettre en exergue un piège dans lequel tu me semble tomber. Le piège est le suivant: un programme ne s'adresse pas qu'à l'ordinateur. Il s'adresse aux développeurs qui travaillent dessus, et en particulier à celui qui est en train de l'écrire. Dans le cas présent, c'est toi-même.
Ce que j'essaie de dire (mais c'est compliqué à expliquer, c'est pourquoi je voulais amener cette réflexion petit à petit) c'est que l'architecture de ton programme doit avoir un sens pour l'être humain. C'est vraiment primordial. Moins l'architecture est sensée, plus il va être difficile (et de façon exponentielle) de faire ce que l'on souhaite.

Et pour que l'architecture est un sens pour l'être humain, il faut se baser sur une logique humaine. Avant de concevoir une classe, il faut penser au rôle de cette classe. Mais y penser de façon "humaine". Est-ce qu'un chien est un animal? oui, donc la classe chien hérite de la classe animal, et le reste s'emboitera tout seul.
L'exemple du logger est un autre bon exemple. Pourquoi le moteur (engine) devrait posséder le logger? Cette question n'a pas de réponse, c'est donc que le moteur n'a pas a posséder le loggeur.
Le fait de répondre à cette question évite ensuite une avalanche de problèmes. Par exemple, si tu avais mis ton logger dans le moteur, et sans parler des problèmes de sécurité, de robustesse et de références, comment aurais-tu fais si tu avais dû logger des choses avant que le moteur ne soit créé? (et il n'y a aucune raison pour que cela n'arrive jamais. Cela peut ne jamais arriver, mais en aucun cas on en est sûr.).

Au cas où, je te propose de jeter un coup d'oeil sur le code du petit jeu que je suis en train de programmer. Voici le dépôt:
https://yatus.svn.sourceforge.net/svnroot/yatus

Tu trouveras, entre autres, le logger que j'ai implémenté il y a des années (je ne me souviens même plus quand) et que j'utilise dans presque tous mes projets c++. Il est simplissime et comporte de nombreuses limitations, mais tu constatera, par exemple, que comme par hasard, c'est un singleton.

[Joel F]

Personellement, je pense que les objets sont des Drawables et implemente un patetrn Composite (comem ca aggregation d'objet est un drawable qui draw ses composants).

Ensuite, tu as une classe Renderer qui prend en parametere de sa methode principale une colelctiond e Drawable* et ne fait que les afficher.

Cette meme collection est utilisee par le moteur de jeu "logique".

Ensuite ton GameEngine ets instancié avec un Renderer + un GameLogic + ce conteneur de Drawable qui passe du Renderer au Logic de frame en frame.

Pas de singleton, pas d'heritage foireux.