Constructeur : appel du constructeur d'une classe ancêtre

Hello,

Soit la hiérarchie A <- B <- C (A étant la classe racine).

Si je fais

C::C(int param) : A(int param) {}

le compilateur dit que A n'est une base, ni un membre.

Ne peut-on appeler que le constructeur de la classe mère immédiate, et pas une classe située plus haut dans la hiérarchie ?

Merci.

Citation:

---

Envoyé par oodini

Hello,

Soit la hiérarchie A <- B <- C (A étant la classe racine).

Si je fais

C::C(int param) : A(int param) {}

le compilateur dit que A n'est une base, ni un membre.

Ne peut-on appeler que le constructeur de la classe mère immédiate, et pas une classe située plus haut dans la hiérarchie ?

Merci.

---

Je serrais tanté de dire non, tu ne peux utiliser que le constructeur de la classe de base, dans ton cas B.
Un besoin trahie un problème de conception.
Ce que tu peut faire c'est appeler le constructeur de A par l'intermediaire de B

Code:

---

1 2 3

B::B(int param) : A(int param) {} C::C(int param) : B(int param) {}

---

Citation:

---

Envoyé par Syl_20

Je serrais tanté de dire non, tu ne peux utiliser que le constructeur de la classe de base, dans ton cas B.
Un besoin trahie un problème de conception.

---

En fait, il faudrait que C hérite publiquement de A, et privativement de B.
Mais c'est de l'héritage multiple, et mon chef n'en veut pas...

Citation:

---

Envoyé par Syl_20

Ce que tu peut faire c'est appeler le constructeur de A par l'intermediaire de B

---

Oui, c'est ce que je fais actuellement.

Salut,

Si une classe C hérite d'une classe B qui hérite elle-même d'une classe A, il est normal que le constructeur de C se base sur... un des constructeur de B.

En effet, tu ne peux obtenir un objet de type C complètement construit qu'au départ d'un... objet de type B lui-même complètement construit.

Et, comme tu ne peux envisager d'avoir un objet de type B complètement construit qu'après... en avoir appelé le constructeur (qui aura lui-même assuré une construction complète d'un objet de type A par appel du constructeur ad-hoc), ben, on se rend bel et bien compte que tout classe qui hérite d'une autre ne devra, en tout état de cause, qu'appeler le constructeur de la classe mère directe.

Le seul cas dans lequel on puisse envisager de "contrevenir" à ce principe immuable est le cas de l'héritage virtuel, qui ne présente un intérêt que dans le cadre d'un héritage multiple dont pourrait résulter un héritage en diamant.

De manière générale, si, en faisant hériter une classe qui en hérite elle-même d'une autre, tu en viens à vouloir modifier la manière dont le constructeur de la classe ancêtre est invoqué par celui de la classe "intermédiaire", tu dois te dire que tu est vraiment tout près d'un problème de conception majeur.

Dans le meilleur des cas, il peut "suffire" de simplement prévoir un constructeur supplémentaire (qui peut parfaitement ne pas être public ;)) dans la classe intermédiaire qui aura comme principale utilité d'appeler...le constructeur de la classe "ancêtre" adéquat, dans le pire (mais souvent aussi dans le plus courent) des cas, il est sans doute plus qu'urgent de réévaluer les relations entre les différentes classes ;)

Concernant les problèmes de conception, C n'a pas besoin de la spécialisation offerte par B, mais a besoin de membres de A.
Et les fonctionnalités de C ne doivent être applicables qu'aux objets de type B.

Quelle serait la conception idéale, selon vous ?

Nous partons dans un domaine beaucoup trop particulier pour nous permettre de parler de manière générale, et il serait donc intéressant de savoir exactement ce que sont et ce que font les classes A, B et C, mais, de manière générale, tu devrais réfléchir à avoir:

• La classe A qui est la classe de base
• la classe B qui hérite de la classe A
• la classe C qui hérite de la classe B
• éventuellement une amitié entre la classe C et la classe B (ou inversement)
• un passage d'argument de type C ou de type B respectivement dans les fonctions de B et de C qui nécessitent... l'accès à l'autre type
• éventuellement, une aggrégation ou une composition de C dans B et / ou de B dans C ( selon la situation particulière à laquelle tu es confronté)

Je tiens, au passage, à rappeler que l'héritage est une relation EST-UN qui implique de respecter le LSP (en francais: le principe de substitution de liskov... une recherche sur le forum te permettra surement de comprendre ce que c'est, en m'évitant de repartir sur l'écriture d'un roman :D)

Citation:

---

Envoyé par oodini

Concernant les problèmes de conception, C n'a pas besoin de la spécialisation offerte par B, mais a besoin de membres de A.
Et les fonctionnalités de C ne doivent être applicables qu'aux objets de type B.

Quelle serait la conception idéale, selon vous ?

---

C hérite de B puisque tu dit que C est une sorte de B

Citation:

---

Et les fonctionnalités de C ne doivent être applicables qu'aux objets de type B.

---

Et pour ça

Citation:

---

Concernant les problèmes de conception, C n'a pas besoin de la spécialisation offerte par B, mais a besoin de membres de A.

---

tu redefinies les methodes virtuelles de B qui vienne de A pour qu'elle appelle ce qui est definie dans A. Tu bénéficies des memebres de A à travers B.
genre

Code:

---

1 2 3 4 5

C::Machin(int param) { A::Machin(param); }

---

Je n'ai pas d'autres idées à te proposer:(

Salut

Citation:

---

Envoyé par oodini

Et les fonctionnalités de C ne doivent être applicables qu'aux objets de type B.

---

Bizarre. On dirait que c'est à l'envers. Un objet de type B ... est un objet de type B pas C :koi:

Composition C/A et héritage de B (qui n'a peut être pas besoin d'hériter de A) ? Ou DP décorateur ?

Merci à tous pour vos réponses. Soyez assurés que j'ai réfléchi à chacune d'entre elles.

En fait, B n'offrant que des fonctions à utiliser dans des classes filles particulières de A, je pense que cela devrait être implémenté en termes de "politique". Les filles de A utilisant ou pas cette politique.

Mais mon chef étant de la vieille école, il ne me laissera pas non plus explorer cette voie...

Hum je me doute que certains vont crier au loup suite a ce que je vais dire, mais une méthode init() ne serait pas ce qui irait le mieux dans ton cas ?