Héritage avec droits d'accès différents..

Bonjour,

Il était difficile de faire tenir l'étendue du problème dans le titre, aussi il n'est pas forcément très bien choisi (mais vous en jugerez après la lecture de la question). J'ai une hiérarchie de classe sur 3 niveaux, et je voudrais que la dernière hérite publiquement de la première, mais "protégément" (o_O) de la seconde. En gros :

Code:

---

1 2 3

class A; class B : public A; class C : protected B, public A;

---

Évidemment ce serait trop beau si ça marchait tel quel (même avec class B : virtual public A; ).

Le problème est épineux puisque la classe C a un comportement vraiment similaire à B (avec des données membres en plus). En revanche, l'utilisateur ne devrait pas pouvoir modifier les données de B via C..

Alors, est-ce seulement possible de faire ça en C++ ?
D'avance merci.

PS: en dernier recours, je pourrais masquer les méthodes indésirables de B en private dans C, mais bon.. bof.

Euh... ça sent pas bon ta conception là... :?

C'est pas plutôt une composition qu'il te faudrait là? Ou un pattern Proxy? Je lance des trucs un peu au pif là, mais si tu pouvais nous en dire plus, on pourrait sans doute être plus précis! ;)

C'est vrai qu'un héritage pareil laisse un peu pensé que la conception est peut-être pas trs bien pensée... (m'enfin, je dis ça, c'est peut-être que je suis pas un fan du modèle de l'héritage multiple ;) )

Mmh, en fait il s'agit d'un moteur 2D basique qui fonctionne avec DirectX.

J'ai une classe virtuelle pure Object2D qui regroupe les données et méthodes communes à tous les objets 2D. Cette classe ne contient que des données "abstraites", mais pas au sens C++ du terme, comprenez tout ce qui décrit théoriquement l'objet (position, visibilité, etc. mais pas de vertex buffer et tous ces trucs là).

De cette classe dérive donc Quad, qui comme son nom l'indique.. est un polygone à 4 sommets. Elle, en revanche, contient les données réelles (tableau des points, toussa).

Et donc, pour finir, une classe Sprite qui est.. un sprite (une image quoi). Ma logique consiste à penser que le sprite est simplement un quad avec une texture. Dans les faits, c'est exactement ça, j'applique une texture sur mon quad, et paf chocapic. Cependant, la taille du sprite, par exemple, doit dépendre de la taille de l'image originale ; alors que la taille du quad est choisie par l'utilisateur.. Donc pour le coup, les méthodes SetWidth et SetHeight du quad ne devraient pas être disponibles pour un sprite, alors que SetPosition de Object2D lui est indispensable..

Donc ? Problème de conception ?

Sans aller plus loin, est-tu sur que tu ne veux pas de SetWidth et SetHeight dans ta class sprite? Çà veu dire que tu t'interdit de redimensionner tes images? Je n'ai jamais fait de DirectX, mais en openGL, la dimension de l'image et celle du quad n'ont absolument pas à être liées.

A partir de la tu peu hériter de la class quad, et faire un héritage propre.

Autrement, tu fais un truc bourrin ;)

Toutes les méthodes de ta classe C qui accède à la classe B tu les mets en const ;)

Citation:

---

Envoyé par Nogane

Çà veu dire que tu t'interdit de redimensionner tes images? Je n'ai jamais fait de DirectX, mais en openGL, la dimension de l'image et celle du quad n'ont absolument pas à être liées.

---

Exact ! Oui je voulais interdire le redimensionnement du quad, préférant utiliser la matrice scale pour le changement de taille. Mais bon effectivement, dans l'absolu ça ne pose pas de problème de l'autoriser..

Citation:

---

Envoyé par pyknite

Toutes les méthodes de ta classe C qui accède à la classe B tu les mets en const

---

o_O Hem, je ne vois pas trop où tu veux en venir, mais ça ne changera rien au fait que Sprite comportera toutes les méthodes publiques de Quad, et c'est ça que je ne voulais pas..

Enfin bon, ça me permet au moins de savoir que l'héritage ne permet pas ce genre de trucs en C++. Je vais sans doute finir par autoriser tous ces trucs sur mes sprites.
Merci.

Edit: y'a pas une balise [contourné], parce que là on peut pas vraiment dire que c'est résolu..

Tu as besoin du polymorphisme ?

Parce que, si tu fais un héritage protégé de B, il ne sera plus polymorphique ?

Si je suis bien ce que tu veux faire, tu aurais besoin que :
- C soit un A
- B soit un A
- C ne soit pas un B
- C incorpore des fonctionnalités de B
- les fonctionnalités de B incorporés dans C travaillent sur le même A que les fonctionnalités que tu rajoutes dans C

La bonne conception que je vois, dans ce cas, c'est :
- définir une interface IA
- A implémente IA
- B hérite publiquement de A
- C implémente IA, et a un membre protégé de type B (composition).

Ça t'oblige à réimplémenter dans C l'interface IA (juste un wrappeur pour appeler les méthodes du membre B, et peut-être qu'avec de la métaprogrammation, on peut le faire faire par le compilo, à creuser, mais s'il n'y a qu'une classe C ça ne sert pas à grand chose), mais ça me semble correspondre à ton besoin.