Problème de design sur une hiérarchie d'objets [Résolu]

[LittleWhite]

Bonjour,

Je suis sur un nouveau programme OpenGL. À la base, tout objets OpenGL est identifiable avec un GLuint. Pour chaque type d'objet OpenGL, nous avons une fonction associée, créant l'objet du coté de la bibliothèque et nous retournant l'identifiant.

Je cherche en quelque sorte à encapsuler ce design.

Au début, je pensais faire un objet GLObject parent de tous, de la façon suivante :

Code c :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
#ifndef GLOBJECT_HPP
#define GLOBJECT_HPP
 
#include <GL/glew.h>
 
class GLObject
{
    protected:
 
        GLuint m_glID;
 
        virtual void create()=0;
        virtual void destroy()=0;
 
    protected:
 
        GLObject():m_glID(0) { create(); }
        virtual ~GLObject() { destroy(); }
};
 
#endif

Comme cela, une classe Texture hérite de GLObject et doit réimplémenté les fonctions create() et destroy() en appelant les fonctions OpenGL appropriées.

Mais, le compilateur a voulu s'en mêler et m'a signalé que je faisais surement un truc de mal avec mes appels à des fonctions pure dans le constructeur / destructeur.
Du coup, j'imagine que j'ai un problème de design.

Pourquoi ne pas vouloir faire l'appel des fonctions OpenGL dans les constructeurs / destructeurs, à vrai dire je ne suis pas trop sur. Principalement, car je souhaitais avoir une fonction séparée pour la gestion de OpenGL (séparée de la construction de l'objet). Enfin bref, cela est surement idiot, surtout que je l'appel dans le constructeur afin d'être bien sur qu'elle soit appelée.

Par contre, je me demande comment vous feriez ?
L'avantage d'avoir une classe GLObject, c'est que je pourrai avoir une banque d'objet qui pourrait même indiquer l'utilisation faite des objects OpenGL et permettre leurs destruction automatiquement.

[Joe Dralliam]

Bonsoir,
Personnellement j'ai du mal a voir l’intérêt de tels fonctions... Après tout la classe Texture possède elle aussi un constructeur et un destructeur : pourquoi ne pas appeler les fonctions OpenGl dedans ? Et puis ça me parait bizarre que la classe de base s'occupe de dire aux classes filles qu'elle doivent s'initialiser alors que sa propre initialisation n'est pas terminée (puisqu'on est pas sorti de son constructeur)

[koala01]

Salut,

Il ne faut pas oublier que, dans le constructeur et dans le destructeur, on ne connait que le type de l'objet que l'on est occupé à (créer ou à détruire , évidemment) et de ses parents...

ou, plutot, dans l'autre sens : on ne connait rien, dans le constructeur ou dans le destructeur d'une classe, des classes qui peuvent éventuellement dériver de celle sur laquelle on travaille

Cela implique que, si tu fais appel à une fonction virtuelle dans le constructeur (ou dans le destructeur) de la classe de base, c'est la version de la classe de base de la fonction qui sera appelée, et non une quelconque redéfinition de celle-ci

Or, si ta fonction est virtuelle, c'est parce que tu t'attends à ce qu'elle réagisse correctement pour le type dérivé dans lequel elle est redéfinie

Le compilateur a donc deux fois raison de refuser de tels appels :

1. Parce que, au niveau de la classe de base, il s'agit de fonctions virtuelles pures, ce qui signifie "sans contenu"
2. parce que, si tu fournissait un comportement à ces fonctions pour le type de base, ce serait ce comportement précis qui serait utilisé, et non le comportement particulier du type dérivé, et auquel tu t'attends sans doute

A bon entendeur

[Xtrem_Voyageur]

Salut LittleWhite!
Ca fait longtemps que je ne suis pas venu sur le t'chat

J'ai lu en diagonale mais comme l'a dit Koala, n'appelle jamais de fonctions virtuelles dans les constructeurs et destructeurs.
Maintenant, je ne suis pas sûr d'avoir saisi ce que tu veux réellement faire mais un design pattern pourrait peut-être t'aider, Abstract Factory / Factory Methods.

Si tu peux développer, en donnant une hiérarchie de classes et l'utilisation que tu en ferais, cela sera plus aisé de t'apporter une réponse appropriée.

[LittleWhite]

Il est plus qu'évident que mon design était pourri et irréfléchi.
Pour la Factory, je pense que cela sera pratique surtout si je veux faire un suivi des objets crée.
Du coup, je vais partir sur un objet GLObject qui ne contiendra qu'un GLint et qui sera hérité.

Merci pour vos réponses

[koala01]

Envoyé par LittleWhite

Il est plus qu'évident que mon design était pourri et irréfléchi.
Pour la Factory, je pense que cela sera pratique surtout si je veux faire un suivi des objets crée.
Du coup, je vais partir sur un objet GLObject qui ne contiendra qu'un GLint et qui sera hérité.

Merci pour vos réponses

Oui, mais... hummm!!!...

Je ne dis pas que ce n'est pas la solution, mais, ma grosse crainte, c'est que tu finisse, à cause de ce "god object", par faire cohabiter des poires avec des voitures au seul prétexte qu'elles ont toutes les deux un numéro et une couleur

si tu crées ton "GlObject", quelle en sera la responsabilité

Cette responsabilité sera-t-elle compatible avec les responsabilité des classes qui en héritent

Ne peut on pas envisager de dire que le fait de fournir un moyen permettant d'obtenir un identifiant (unique) telle qu'une fonction id() n'est qu'un prérequis d'interface commun à tout objet qui sera manipulé, sans pour autant que cela ne nécessite une hiérarchie unique et monolithique

Mieux encore, ne peut on pas envisager le fait que tout ce qui a traiit à OpenGL n'a strictement rien à voir avec la hiérarchie d'objet que tu t'apprêtes à créer, dans le sens où tes objets n'ont, a priori, aucune raison d'avoir la responsabilité de leur affichage

Je n'ai pas de réponse toute faite à ces questions (ce qui ne m'empêche pas d'avoir mon avis ), ne sachant pas exactement quels sont tes objectifs, et je me contente d'énumérer certains écueils qu'il me semble difficile d'éviter en partant sur le principe que tu envisages d'utiliser

Peut etre serait-il utile que tu réfléchisse à la réponse à donner à chacune de ces questions, ne serait-ce que pour t'assurer que tu auras pris la bonne décision en pleine connaissance de cause

[LittleWhite]

La responsabilité de mon object ? Je suis à la limite de répondre : "Aucune"
Le GLObject ne contient qu'un ID et rien d'autre. Il y a un getter et c'est tout. Au final, peut être que je n'ai absolument pas besoin de faire un tel objet.

Toutes classes qui héritera de cet objet, aura besoin de l'ID. Par contre, un héritage me donne l'impression que ce n'est pas le bon choix, et que je devrais juste avoir un membre GLObject dans ces classes.

Pour l'instant, l'affichage est géré par un Renderer externe, qui utilisera les fonctions des classes héritants de GLObject.

SInon, je viens de penser, que je pourrais peut être rajouter des fonctions bind() / unbind() virtuelle pure .

[koala01]

Envoyé par LittleWhite

La responsabilité de mon object ? Je suis à la limite de répondre : "Aucune"

C'est bien là tout le problème!!! je ne sais pas s'il est pire d'avoir une classe ayant trop de responsabilité ou une classe n'en ayant aucune de clairement établie

L'un dans l'autre, je ne suis pas loin de penser que, si une classe n'a pas une responsabilité clairement définie, elle risque, à terme, de se retrouver avec tout plein de responsabilités, non

Le GLObject ne contient qu'un ID et rien d'autre. Il y a un getter et c'est tout. Au final, peut être que je n'ai absolument pas besoin de faire un tel objet.

Tu as, peut etre, besoin d'un tel objet, mais, de là à en hériter (au sens POO s'entend )!!!

Toutes classes qui héritera de cet objet, aura besoin de l'ID. Par contre, un héritage me donne l'impression que ce n'est pas le bon choix, et que je devrais juste avoir un membre GLObject dans ces classes.

Je ne crois pas que l'héritage soit consistant ici, parce qu'il ne respecterait absolument pas LSP : Ta classe n'ayant aucune responsabilité (ou les ayant toutes ), comment veux tu définir si, oui ou non, les objets qui en dériveraient sont bel et bien des objet ayant cette responsabilité


Comme je te l'ai dit, je ne doute pas que l'interface proposée par cette classe soit un prérequis pour tout objet que tu manipulera, mais, dans quelle mesure ne pourrais tu pas te tourner soit vers une composition classique, soit vers une solution à base de CRTP

Pour l'instant, l'affichage est géré par un Renderer externe, qui utilisera les fonctions des classes héritants de GLObject.

Et surtout, tes objets réels qui ne sont sans doute absolument pas des GLObjects

Il peut sembler cohérent de créer une hiérarchie de classes dont la responsabilité sera d'afficher (au final sous OpenGL) tes objets "business", mais, a priori, tes objets business n'ont strictement rien à voir avec GLObject : leur responsabilité sera sans doute de tout et de n'importe quoi... sauf l'affichage

SInon, je viens de penser, que je pourrais peut être rajouter des fonctions bind() / unbind() virtuelle pure .

Peut etre, mais qu'est ce que cela donne comme responsabilité à ta hiérarchie de classes

Je ne suis contre rien en particulier, j'essaye juste de t'inciter à réfléchir au besoin que tu essayes de rencontrer, et, surtout, d'arriver au besoin que cette hiérarchie de classes serait sensée couvrir

[DonQuiche]

Bonsoir.

D'abord, sur le GLObject... Certes, tous les objets OGL ont un ID. Est-il pour autant nécessaire de créer une classe qui ne contiendrait qu'un seul champ ? Voyons les reponsabilités possibles :

• Tu parlais de pouvoir ainsi faire une banque d'objets que tu pourrais détruire automatiquement mais n'importe que objet peut être détruit via l'opérateur delete, pas besoin qu'il hérite de GlObject. D'ailleurs, si tu regardes ton design proposé, tes create et destroy n'étaient que des constructeurs et destructeurs. A la rigueur tu pourrais vouloir implémenter un système de compteur de références mais est-ce que ça correspond à la façon dont tu veux gérer la durée de vie de tes objets ?
• Tu évoques des "bind" / "unbind"... Ça me semble une mauvaise idée : de telles fonctions impliquent qu'une classe externe va avoir la tâche d'appeler les commandes OGL en connaissant exactement l'identité des classes manipulées. Autrement dit, cette classe externe va, pour une texture par exemple, appeler une série de gl*** relatifs à la gestion des textures et, au milieu de ça, insérer un tex->bind() qui n'exécutera qu'une ligne ? Ou bien comptes-tu en fait refaire l'API OGL sous forme objet en exposant pour chaque commande gl*** une fonction membre ?
• A la rigueur ils pourraient fournir aux héritiers un mécanisme d'assertion de l'identité du thread courant puisqu'un objet OGL ne peut être créé ou modifié que sur certains threads (le thread de rendu ou, dans certains cas, des threads associés).

Si je puis me permettre une esquisse de hiérarchie objet... Au niveau intermédiaire tu as deux catégories d'objets essentiels qui doivent dialoguer l'un avec l'autre : les matériaux/shading (marbre, bois, etc : ils sont composés d'un ensemble de textures, d'options de rendu, peut-être de morceaux de shaders, etc) et les forme/shapes. Tous deux peuvent influencer le choix des shaders, textures, format des sommets, états à utiliser, groupes de rendu (objets statiques ou dynamiques, opaques ou transparents, etc), méthode de rendu (multipasse, etc). Appelons cet ensemble d'états un procédé de rendu / RenderProcess.

De là tu dois donc mettre en place un dialogue entre le matériau et la forme pour qu'ils produisent conjointement une série de "primitives" de rendu contenant chacune un procédé de rendu et un maillage. Par exemple tu peux passer la forme en argument au matériau ou lui passer un ensemble d'infos nécessaires. Le matériau produit en retour des primitives, qui peuvent éventuellement être complétées par le matériau.

Après, il ne reste plus "qu'à" passer tout ça dans un BSP, trier selon Z, batcher, etc. Quant à celui qui appellera les commande OGL, le procédé de rendu ou l'un de ses composants est tout indiqué, tout en s'appuyant sur des objets VBO, texture, et compagnie pour éviter les répétitions. A moins que tout ce beau monde ne s'appuie sur une abstraction "backend" qui pourrait être indifféremment implémentée via OGL ou D3D.

[LittleWhite]

Le but final, si un jour je vais jusqu'à ce stage, c'est d'avoir assez d'abstractions pour changer entre OpenGL et D3D. Mais actuellement, mon histoire est que je dois surtout faire une implémentation OpenGL.

Je comprends votre point de vue. Je suis plutôt d'accord pour les matérials / shaders | mesh / texture.
Mais, ma question est du coté de comment on implémenterai l'ID OpenGL pour la texture ...
A priori, le principe simple de base d'avoir un l'ID directement dans la classe Texture ne vous gêne pas. Pourtant, si je veux avoir un gestionnaire d'objet pour faire des stats ou je ne sais quoi ... ils doivent tous hérité d'une classe Object (mais comme cet argument n'est qu'une hypothèse d'évolution, mieux vaut que je ne m'y attache pas).

[gbdivers]

J'avais pas lu cette discussion. On en avait discuter sur le chat.
Tu peux utiliser ici (encore) les classes de traits/politiques (désolé LittleWhite, comme c'est presque les bases de la programmation générique, je te les sors à toutes les sauces )

Sinon, sans template, tu peux aussi créer des fichiers spécifiques pour GL et D3D contenant les typedef et fonctions libres spécifiques (ou des classes utilitaires), qui seront inclus (ou non) à la compilation. Par exemple :

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
// d3d.h
#include <d3d11.h>
#include <d3dx11tex.h>
typdef Texture2D Texture
Texture createTexture(...) { ...*}
Texture openTexture(string const& f) {}
void deleteTexture(Texture& t) { ... }
void bindTexture(Texture const& t) {*...*}
 
// gl.h
#include    <gl\gl.h>
typdef GLuint Texture
Texture createTexture(...) { Texture t; glGenTextures(1, &t); return t; }
Texture openTexture(string const& f) {}
void deleteTexture(Texture& t) { ... }
void bindTexture(Texture const& t) { glBindTexture(GL_TEXTURE_2D, t); }
 
// main.cpp
#ifdef USE_DIRECTX
#   include d3d.h
#elif
#   include gl.h
#endif
 
main() {
    Texture t = createTexture(...);
    bindTexture(t);
    ...
    deleteTexture(t);
}

[LittleWhite]

Merci gbdivers, mais là je doute qu'il faille un traits/politique. Du moins, je ne vois pas où (la question de pose aussi pour OpenAWars pour le moment).
Ah si, vous c'est parce que vous souhaitez faire un truc :

Code :

Renderer<GL> monRendererOpenGL

Ce qui n'est pas mon problème actuel

[gbdivers]

mais là je doute qu'il faille un traits/politique.

Je savais que tu allais apprécier

Je donnais une solution pour :

c'est d'avoir assez d'abstractions pour changer entre OpenGL et D3D

Pas besoin de faire des hériarchies compliqués si une simple compilation conditionnelle résoud le problème.

Ah si, vous c'est parce que vous souhaitez faire un truc :

Plutôt :

Code :

1
2
3
4
5
#ifdef USE_DIRECTX
Renderer<D3D> monRenderer;
#elif
Renderer<GL> monRenderer;
#endif

[koala01]

Envoyé par LittleWhite

Merci gbdivers, mais là je doute qu'il faille un traits/politique. Du moins, je ne vois pas où (la question de pose aussi pour OpenAWars pour le moment).
Ah si, vous c'est parce que vous souhaitez faire un truc :

Code :

Renderer<GL> monRendererOpenGL

Ce qui n'est pas mon problème actuel

Le fait est que c'est, justement, la base de l'ensemble du problème

Il es possible de faire sensiblement la même chose avec DirectX qu'avec OpenGl, mais le moyen d'y arriver sera forcément différent ( ne serait-ce que par le nom de la fonction à appeler )

L'idée est donc de mettre en place ce qui pourrait ressembler à une "façade" fournissant une interface unique adaptée à tes besoins et appelant les fonctions adaptées à la bibliothèques utilisée de manière transparente pour l'utilisateur

Tu as donc une première notion tout à fait transversale qui est le "contexte" d'utiliisation (DX ou Gl, selon le cas) qui pourrait très bien etre représenter par deux (ou plus, si tu décides un jour d'utiliser une autre bibliothèque ) classes vides proche de

Code :

1
2
3
4
5
6
class OpenGL
{
};
class DirectX
{
};

A partir de là, tu crées un ensemble de classes template permettant de fournir les fonctions minimales dont tu as besoin qui seront spécialisées en fonction du contexte (pour appeler la bonne fonction DX ou Gl au bon moment), et, une fois que tu disposes de toutes tes "fonctions de base", il ne te reste plus qu'à les utiliser en spécialisant tes classes avancées sur base du contexte

Après cela, quelques ifdef et un -DOpenGl ou un -DDirectX peuvent parfaitement suffire pour te permette de passer aisément d'une compilation prévue pour OpenGl à une compilation prévue pour DirectX

Mais cela montre bel et bien que la notion même d'une classe OglObject (ou quel que soit son nom) dont la responsabilité n'est pas clairement définie ne rime pas à grand chose

Maintenant, si, dans ta façade, tu venais à créer une classe DrawableObject à spécialiser en fonction du contexte et fournissant des services cohérents, il en irait tout à fait autrement (note que le fait de le nommer de la sorte pré-conditionne l'usage qui en sera fait, et c'est très bien : cela a l'énorme avantage de lui donner une responsabilité claire et précise )

[3DArchi]

Salut,

Envoyé par LittleWhite

Pourtant, si je veux avoir un gestionnaire d'objet pour faire des stats ou je ne sais quoi ... ils doivent tous hérité d'une classe Object (mais comme cet argument n'est qu'une hypothèse d'évolution, mieux vaut que je ne m'y attache pas).

C'est une des causes d'apparition des super-objets : comment faire une collection d'objets différents ? L'héritage n'est pas une bonne réponse. Utilises des conteneurs polymorphes selon la problématique (boost.variant,any,fusion...) et laisses les choux et les carottes indépendantes l'une de l'autre.

(P.S. : fonctions virtuelles dans les constructeurs)

[DonQuiche]

Envoyé par koala01

Maintenant, si, dans ta façade, tu venais à créer une classe DrawableObject à spécialiser en fonction du contexte et fournissant des services cohérents, il en irait tout à fait autrement

Sur ce seul point, une classe DrawableObject serait en fait indépendante du choix OGL/D3D. Seules les classes de bas niveau (maillage, texture, etc) seraient liées à ce choix, une classe DrawableObject est d'un niveau bien plus élevé. Au mieux elle s'appuie sur les façades mais il est aussi possible qu'elle en soit totalement indépendante car on aura dû rajouter d'une couche intermédiaire entre les deux niveaux.

Typiquement, on pars d'un graphe de haut niveau (voiture, camion, bonhomme, etc) et on arrive à un graphe de bas niveau (maillages, états de rendu, etc). Entre les deux on peut avoir une foule de graphes intermédiaires.