Discussion :

[Rodrigue]

Bonjour,

Existe-t-il un moyen d'initialiser un objet réquérant des paramètres dans une de mes classes sans passer par des instanciations dynamiques?
Voici un exemple pour être plus clair.
J'ai des objets objGrille et objMaillage3D. Leurs constructeurs sont de la forme:

Code :

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

1
2
objMaillage3D(std::string fileName);
objGrille(const objMaillage3D &mailles);

A chaque objet objMaillage3D doit correspondre un objet objGrille (il s'agit d'un partionnement des mailles de l'objet dans l'espace). Est-il possible d'initaliser une variable private objGrille de mon objet objMaillage3D dans le constructeur de celui-ci sans passer par une instanciation dynamique?

Plus dans un esprit de conception POO, est-il correct de placer une variable objGrille dans un objet objMaillage3D ou existe-t-il une meilleure solution?
Je pense par exemple à l'héritage... Ma classe objMaillage3D aura toujours une grille donc pourquoi ne pas la faire hériter de mon objet objGrille...
Ou pourquoi ne pas instancier mon objet objGrille3D en dehors de la classe objMaillage3D dans le corps de mon programme principale...

Par avance, merci!
Cordialement,
Rodrigue

[Ti-R]

Cela dépend de ce que tu souhaites faire !

Si tu souhaites réutiliser les fonctions membres de la class objGrille3D dans ta class objMaillage3D, avec peut être une surcharge en plus, autant hériter.

Si c'est juste pour stocker des informations et que tu n'as pas besoin d'avoir toutes les fonctions membres public accessibles depuis l'extérieur, autant mettre une objet objGrille3D en private dans ta class objMaillage3D.

Ce n'est que mon point de vu.

[JolyLoic]

Je ne suis pas certain que c'est ce que tu veux, mais la syntaxe d'initialisation d'une donnée membre est la suivante :

Code :

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

1
2
3
4
objMaillage3D::objMaillage3D(std::string fileName) :
  maGrille(...)
{
}

[rigobert]

Si tu souhaites réutiliser les fonctions membres de la class objGrille3D dans ta class objMaillage3D, avec peut être une surcharge en plus, autant hériter.

C'est peut-être un peu rapide comme analyse.

Le principe de base de l'héritage en POO est que pour que B puisse dériver de A, B doit être un A.

Exemple :

tu as une classe Félin avec une méthode chasser();
tu voudrais créer une classe Loup ayant aussi la méthode chasser();
eh bien malgré cela, Loup ne peut dériver de Félin parce que le loup n'est pas un félin (arf).

Ca parait concon dit comme ça, mais c'est pourtant un moyen très simple d'éviter des erreurs de conception qui peuvent coûter très cher par la suite.

[Rodrigue]

Bonjour,

Donc si je suis ton raisonnement, le fait que mon maillage3D ne soit pas une grille implique que je ne dois pas le dériver de l'objet grille...
Pourtant, un maillage n'a qu'une et une seule fois une grille. De plus dans cet objet de grille, je devrais passer mon objet maillage.
Si je déclare mon objet grille dans ma classe maillage3D, d'une part je pourrais en déclarer plusieurs, ce qui n'est pas génial niveau conception (j'empêche comme ça de faire quelque chose de bête) et je devrais passer le pointeur this de mon objet maillage3D pour initialiser ma grille.. ça me semble mal conçu! Qu'en penses-tu?

[Rodrigue]

Je ne suis pas certain que c'est ce que tu veux, mais la syntaxe d'initialisation d'une donnée membre est la suivante :

Code :

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

1
2
3
4
objMaillage3D::objMaillage3D(std::string fileName) :
  maGrille(...)
{
}

Merci! C'est ce que je voulais... Il est donc impossible de faire ça autre part que dans le constructeur.

[Ti-R]

C'est peut-être un peu rapide comme analyse.

Le principe de base de l'héritage en POO est que pour que B puisse dériver de A, B doit être un A.

Exemple :

tu as une classe Félin avec une méthode chasser();
tu voudrais créer une classe Loup ayant aussi la méthode chasser();
eh bien malgré cela, Loup ne peut dériver de Félin parce que le loup n'est pas un félin (arf).

Ca parait concon dit comme ça, mais c'est pourtant un moyen très simple d'éviter des erreurs de conception qui peuvent coûter très cher par la suite.

Oui j'ai fait un raccourci il est vrai . Mais j'ai du mal à concevoir ce que représente son objGrille par rapport à son objet class objMaillage3D

S’il doit avoir 1 seul objet objGrille dans la scène par objet ?
Si un objGrille représente des coordonnées de l'objet dans la scène?

Pour répondre à ta question Rodrigue, il faudrait expliciter le rôle de objGrille, et son rôle en relation avec objMaillage3D.

Car si on ne sait pas si objGrille est un animal ou un félin, comment dire si le loup peut hériter de la fonction membre chasser(); de l'objGrille

[loufoque]

Existe-t-il un moyen d'initialiser un objet réquérant des paramètres dans une de mes classes sans passer par des instanciations dynamiques?

Bien entendu.
Cela se fait avec une "initialization list".

[Rodrigue]

En effet, je vais détailler:
objMaillage3D est un objet contenant entre autres toutes les mailles de mon objet à savoir pour l'instant des facettes triangulaires 3D.
objGrille quand à lui sert essentiellement à accélérer les calculs (le calcul des intersections en fait), il s'agit d'associer chacune de mes facettes à une cellule/case de ma grille.
J'ai un seul objet dans mon programme mais celui-ci est composé de plus d'une dizaine de milliers de facettes pour l'instant ...

[Ti-R]

Si objGrille est juste une classe, avec seulement des fonctions membres sans variables membres, autant le déclarer en private static dans ton objet.

Si il y a des variables membres, qui sont locale à l'objet, le mettre en private.

Maitenant qu'on sait que l'objet n'est la que pour accélérer des calculs, cela n'a aucun intérêt de faire de l'héritage.

[Rodrigue]

Ok! Merci beaucoup
C'est un de mes défauts (ou qualités, ça dépend): je me pose trop de questions et à la fin après avoir imaginé milles et un scénario, j'en arrive à hésiter un peu sur tout