niveau d'héritage ?

Bonjour,
j'ai une class A qui herite de B, B hérite de C etc, etc, etc

Pour vous qu'elle devrait être le niveau maximum pour les héritage successive?
Pour moi, 4-5 est le maximum. Aprés je pense que c'est une mauvaise conception des class
merci

Salut,

Pour moi : 3.

Une interface (que des virtuelles pures), une classe abstraite (qui factorise des traitements) en-dessous et des classes concrètes encore en-dessous.
Sachant qu'en pratique la classe abstraite n'apparaît que lors d'un remaniement pour réduire une duplication dans les classes concrètes...

MAT.

Salut,

Je ne crois pas qu'il soit opportun de se placer des limites trop strictes à ce sujet.

Si le point de vue de Mat est tout à fait sensé en générale, il n'en demeure pas moins qu'il m'est déjà arrivé d'avoir 5 niveau d'héritage, tout en respectant pleinement le principe énoncé dans effective C++ (ou est-ce l'un des autres :question:) d'avoir recours à l'héritage pour spécialiser, et non pour implémenter.

Mais, si tu mets une limite aux niveaux d'héritage, tu risque de te retrouver face à un problème lorsqu'il s'agira - par exemple - de modéliser les différents êtres vivants.

En effet, bien que cela ne respecte plus forcément le principe de la spécialisation cher à Ac++, si tu dois modéliser les différentes classes, ordres, sous classes, sous ordres et autres de l'évolution, tu n'auras pas le choix, et tu te retrouvera très rapidement avec 8 à 10 niveaux d'héritage... si pas plus.

Et ce n'est pas un domaine isolé, car il serait aussi possible de parler des classes représentant les éléments visuels d'une interface graphique et tant d'autres domaines ;)

De plus, on peut estimer que, si la norme prévoit qu'un compilateur qui la respecte doit au minimum pouvoir supporter 16384 classe de base directes ou indirectes, c'est que le comité ne voulait en tout cas pas placer de restriction trop subjective en la matière, même si l'idée n'est visiblement pas d'inciter les gens à respecter Ac++ :aie:

Bien sur, y as toujours des exceptions.
Ce que je veut dire c'est quand on arrive à un certain niveau, il faut mieux se demander pourquoi.

Citation:

---

Envoyé par koala01

En effet, bien que cela ne respecte plus forcément le principe de la spécialisation cher à Ac++, si tu dois modéliser les différentes classes, ordres, sous classes, sous ordres et autres de l'évolution, tu n'auras pas le choix, et tu te retrouvera très rapidement avec 8 à 10 niveaux d'héritage... si pas plus.

---

Pourquoi de pas plustôt utiliser des class poltique ?

ps :C'est quoi Ac++?

Citation:

---

Envoyé par Mongaulois

Bien sur, y as toujours des exceptions.
Ce que je veut dire c'est quand on arrive à un certain niveau, il faut mieux se demander pourquoi.

---

Nous sommes donc bien d'accord...

Je voulais principalement attirer l'attention sur le fait que je n'ai rien contre le fait de se donner une limite, pour autant qu'elle soit appliquée de manière raisonnée ;): je suis pour la rigueur, mais contre la rigidité ;):D

Citation:

---

Pourquoi de pas plustôt utiliser des class poltique ?

---

Une classe politique permettra de faire la distinction entre le kangourou et le koala - qui sont tous les deux des marsupiaux - mais il sera bien plus difficile de faire la distinction entre un éléphant - qui est un parchiderme - et une vache - qui est un bovidé - avec une classe politique, alors que tous deux sont des mammifères :aie:

Citation:

---

ps :C'est quoi Ac++?

---

C'est "Advenced C++", qui est l'un des bouquins de la même veine que (more) effective C++ et consors ;)

Citation:

---

Envoyé par Mat007

Salut,

Pour moi : 3.

Une interface (que des virtuelles pures), une classe abstraite (qui factorise des traitements) en-dessous et des classes concrètes encore en-dessous.
Sachant qu'en pratique la classe abstraite n'apparaît que lors d'un remaniement pour réduire une duplication dans les classes concrètes...

MAT.

---

Tu veux dire que le pire cas à envisager c'est l'héritage en diamant ?

Citation:

---

Envoyé par Mongaulois

Pourquoi de pas plustôt utiliser des class poltique ?

ps :C'est quoi Ac++?

---

J'en connais un qui a lu mon article :aie: Ca fait toujours plaisir.

Normalement AC++ c'est pour Accelerated C++ :koi:

Citation:

---

Envoyé par koala01

C'est "Advanced C++", qui est l'un des bouquins de la même veine que (more) effective C++ et consors ;)

---

Le Coplien? Tu fais bien de préciser le titre du livre, car beaucoup comprennent Accelerated C++ quand on dit AC++.

Citation:

---

Envoyé par koala01

Une classe politique permettra de faire la distinction entre le kangourou et le koala - qui sont tous les deux des marsupiaux - mais il sera bien plus difficile de faire la distinction entre un éléphant - qui est un parchiderme - et une vache - qui est un bovidé - avec une classe politique, alors que tous deux sont des mammifères :aie:

---

parchiderme (:aie: pour une fois que c'est pas moi), bovidé, ... ce n'est que du classement.
On pourrais faire une class mono cellulaire et une multi-cellulaire qui utilise des politiques pour :
- environnement
- mode de déplacement
- mode de nutrition
- ...

Car avec l'héritage, un pachyderme ne pourra plus jamais évoluer vers un bovidé (ouai bon c'est un peu n'importe quoi...mais c'est le principe) hors l'évolution pourrais très bien vouloir rapprocher un éléphant et une vache vers une même famille....

Pas d'autre avis?

Ben je sais pas trop. Il y a beaucoup d'exemples de libs/programmes qui ont plus de 5 niveaux d'héritage (les libs d'IHM, les gros progammes...). Je ne pense pas qu'il soit vraiment pertinent de mettre une limite comme ça, absolue.

L'héritage, pour moi, a une signification, donc si ton modèle est sensé, rien n'empêche un grand nombre de niveaux d'héritage. J'ai récemment travaillé sur une application qui sert à communiquer avec une machine assez complexe (un compteur électrique "intelligent"), et le protocole de communication a été implémenté avec beaucoup de niveaux d'héritage (jusqu'à 9 il me semble), la dernière "feuille" de l'arbre d'hériatge étant une trame. Au début ça fait peur, mais en fait, ce design permet d'utiliser ces trames à différents niveaux d'abstraction et ça c'est avéré extrêment pratique.

Citation:

---

Envoyé par r0d

Ben je sais pas trop. Il y a beaucoup d'exemples de libs/programmes qui ont plus de 5 niveaux d'héritage (les libs d'IHM, les gros progammes...). Je ne pense pas qu'il soit vraiment pertinent de mettre une limite comme ça, absolue.

---

C'est pas vraiment une limite absolue, mais un repère. C'est a dire au bout d'un certain niveau (4-5 pour moi ), il faut mieux prendre le temps de remettre en question son architecture avant de continuer...
Dans la plupart dea cas, la réponse Mat007 suffit.
après Y as les ihm... Mais y as pas tant que cela de niveau :
http://doc.trolltech.com/extras/qt43-class-chart.pdf

Tu remarquera quand même que 5 voir 6 niveaux d'héritages sont fréquents dans Qt (ce qui est quand même dans la limite supérieure - et au delà - de celle que tu envisages :D);)

Le tout, étant sans compter que Qt incite fortement à créer des widget personnels, ce qui implique au minimum un niveau supplémentaire d'héritage ;)

De la même manière, tu remarquera que, bien que l'héritage multiple soit généralement décrié, il est également utilisé par Qt en plusieurs occasions...

Je suis d'accord avec le principe qu'il faille se poser la question de savoir si l'arbre d'héritage est cohérent...

Mais, à vrai dire, il faut se la poser en permanence :D: Le simple fait d'avoir un seul niveau d'héritage peut être tout à fait incohérent dans une situation donnée, alors que dans une autre circonstance, il peut être parfaitement cohérent et efficace d'en avoir 10, 12 ou... 100...

Je le redis: s'il est clair qu'il faut absolument rester "aussi simple que la complexité du projet le permet", il ne faut en aucun cas se placer une "limite psychologique" fasse aux possibilités du langage ;)

Personnellement, au delà de 2, je me pose déjà des questions.

En général, je m'interroge sur la notion de sous-type que j'implémente en héritant une classe D de ma classe de base B. Liskov a très justement mis en valeur que lorsqu'on hérite d'une classe, on hérite non seulement de son interface mais aussi des comportements induits par cette interface (ce que je vais appeler à tort le contrat de la classe). L'héritage n'est possible que si le contrat de la classe est parfaitement respecté - c'est à dire si du point de vue du client, le comportement de la classe dérivée est identique au comportement de sa classe de base. Ce qui se traduit par l'énoncé suivant (B. Liskov et J. Wing, "Family Values: A Behavioral Notion of Subtyping"):

Citation:

---

Soit q(x) une propriété prouvable à propos des objets x de type T. Alors q(y) doit être vrai pour les objets y de type S lorsque S est un sous-type de T.

---

Il en ressort que toutes les propriétés q(x) prouvables sur x - le contrat de T - doivent aussi être prouvables sur q(y) - donc que le contrat de S est identique au contrat de T.

Cette relation (qui n'est plus une relation is-a mais une relation behaves-as-a) implique une autre vision de l'héritage et de l'objet en général, puisqu'on se libère progressivement d'une approche ontologique assez classique pour aller vers une approche qui se base sur une abstraction des comportements (ce qui ne veut pas dire que l'approche ontologique n'est pas pertinente; elle reste nécessaire, mais elle est efficacement secondée et dans certains cas remplacée par une approche comportementale).

Dans une approche comportementale, des niveaux d'héritage multiples ne sont plus justifié - en fait, il ne sont même plus justifiables. Il est aisément concevable d'avoir deux niveaux (classe mère et ensemble de classes dérivées), voire trois niveaux dans certains cas, mais redéfinir de manière plus fine le comportement des classes en héritant davantage n'est plus une nécessité.

On peut bien évidemment trouver des contre-exemples, mais ceux-ci sont rares. De fait, leur mise en place résulte d'une réflexion plus importante qui ne laisse pas la place au doute.

Ce qui est frappant, c'est la liberté qu'autorise cette approche: puisque la relation is-a n'est plus automatiquement pertinente, on s'abstrait des raccourcis classiques pour se poser de nouvelles questions. Si, au niveau scientifique, un chat est effectivement un mammifère, est-ce que la classe Chat est pour autant un sous-type de la classe Mammifère ? Qu'en est-il de la classe Humain ? Est-il pertinent de reproduire la hiérarchie scientifique de l'arbre des espèces ? Carre est-il un sous-type de Rectangle ? etc. En plus de cette liberté, le principe de substitution de Liskov aplatit la hiérarchie des classes, ce qui en retour force l'utilisation plus importante de la composition afin d'étendre les comportements - ce qui n'est pas un mal...

Je n'ai pas lu 'Advanced C++', donc je me garderais de dire quoi que ce soit sur ce livre. Les autres livres similaires que j'ai lu (Industrial Strength C++ (ci-dessous ISC++), C++ Coding Standard, C++ Gotchas) ont tendances à dire "il ne faut pas faire si, il faut faire ça" sans se donner la peine de donner une explication correcte du pourquoi. Par explication correcte du pourquoi, j'entends une explication de l'abstraction sous-jacente. Je prends un exemple dans ISC++:
1) la règle énnoncée:

Citation:

---

Rule 10.8: A pointer or reference to an object of a derived class should be possible to use wherever a pointer or reference to a public base class object is used.

---

C'est l'une des simplfication de l'énoncé du principe de substitution de Liskov.
2) l'explication:

Citation:

---

Substitutability is a property of derived classes that will allow you to use objects of these classes without changing code that depends on the base class interface only. If a virtual member function has a precondition and a postcondition, then these must be valid for all implementations of the class interface. If they are not, the derived class should not inherit the base class.
(...)
Substitutability also requires that a derived class always fulfils the base class invariant. Otherwise an object can be put in a state that is not expected by the user of the class.

---

Soit, très bien (ISC++ s'en sort plutôt bien comparé à la vaste majorité des ouvrages qui citent ce principe). Mais pourquoi cette notion de substitutability ? D'où est-ce qu'elle vient, qu'est-ce qu'elle entraine ?

Au final, ce genre d'ouvrage propose des règles, mais sans expliquer la théorie correctement.

(edit) mention spéciale pour "Effective C++" de Scott Meyers, qui parle du comportement des classes (sans citer le mot comportement) (Item 32). Reste que l'explication qu'il donne est moins nébuleuse que les explications trouvées dans les autres ouvrages. Elle a au moins le mérite de parler de sémantique (mais, bien évidemment, sans citer ce mot).

Citation:

---

Envoyé par koala01

Tu remarquera quand même que 5 voir 6 niveaux d'héritages sont fréquents dans Qt (ce qui est quand même dans la limite supérieure - et au delà - de celle que tu envisages :D);)

---

Regarde bien, sur le nombre de classes, très très peu.
Quand je dit 4-5 c'est pour la majorité des cas. Y as toujours un contre exemple.

Code:

---

Le tout, étant sans compter que Qt incite fortement à créer des widget personnels, ce qui implique au minimum un niveau supplémentaire d'héritage ;)

---

Oui, mais cela va au delà de ma question. Hériter correctement d'une lib pour ses besoins est pour moi naturelle. Mais de la même manier, il est très rare de faire plus de deux niveau d'héritage en partant d'une lib.

Je pose cette question (un peu floue dsl) pour voir comment sont comprise et utilisée l'héritage. Et surtout pour améliorer ma conception objet. J'en ai une approche simple et pas toujours assez réfléchie. D'où cette sorte de limite de 4-5 même si je reste souvent sur 3.

La réponse d'Emmanuel Deloget est très intéressante, elle montre une réflexion différente de "un chat est un Mammifère donc une classe chat hérite d'une classe Mammifère".
Je suis d'accord sur

Citation:

---

Au final, ce genre d'ouvrage propose des règles, mais sans expliquer la théorie correctement.

---

Citation:

---

Envoyé par Emmanuel Deloget

lorsqu'on hérite d'une classe, on hérite non seulement de son interface mais aussi des comportements induits par cette interface

---

+1

En C++ on ne dispose pas au niveau du langage de la notion d'interface a la JAVA, on passe par des ABC (Abstract Base Class). Je pense que c'est un critere important a prendre en compte. Si les classes de base sont des ABC, un niveau relativement eleve d'heritage me choque moins que si la classe de base est une grosse classe concrete qui fait beaucoup de choses. La notion d'interface est fondamentale en COM par exemple. Et alors on obtient facilement des niveaux importants sans que cela soit choquant.

Quant a chiffrer le niveau max acceptable, j'avais lu dans des conventions de codage un niveau de 3. Au dela, notre petit cerveau d'humain a tendance a saturer rapidement et a perdre le fil. Mais si on travaille sur une grosse bibliotheque, il peut etre difficile d'y arriver. Voir par exemple la hierarchie de VTK.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

En C++ on ne dispose pas au niveau du langage de la notion d'interface a la JAVA, on passe par des ABC (Abstract Base Class).

---

Je ne comprend pas la différence :cry:

Citation:

---

Envoyé par Mongaulois

Je ne comprend pas la différence :cry:

---

Probablement parce qu'il n'y en a pas. Une ABC en C++ est une interface en Java ou C# (enfin, ça revient à ça, même si les contraintes sont différentes).

Citation:

---

Envoyé par Emmanuel Deloget

Probablement parce qu'il n'y en a pas. Une ABC en C++ est une interface en Java ou C# (enfin, ça revient à ça, même si les contraintes sont différentes).

---

Je me disait aussi.
A votre avis, l'utilisation de politiques peut elle être une solution pour limiter l'héritage. Comme l'exemple (un peu n'importe quoi mais c'est un exemple) que j'avais écrit ici
http://www.developpez.net/forums/sho...10&postcount=8
Personnellement, ce que je reproche à un trop grand niveau d'héritage est :
- Complexité de compréhension pour une personne tierce
- Fait peur à un client
- Debuggage plus complexe
- Difficulté de remodulation du code si besoin

Citation:

---

Envoyé par Mongaulois

Je ne comprend pas la différence :cry:

---

Je me suis pas tres bien exprime :D

Ce que je voulais dire, c'est qu'en C++, ne disposant pas de la notion d'interface au niveau du langage, on la simule au moyen d'ABC.

(ce que je vais dire à est prendre avec des pincettes, ne me pas me plomber si j'ai tord).

En C++, une ABC c'est une classe qui peut avoir des données membres alors qu'en Java, une interface n'a pas de donnée mais juste des fonctions pures ?

Une interface java correspondrait à une ABC C++ où toutes les fonctions membre sont virtuelles pure.

Citation:

---

Envoyé par Mongaulois

Je me disait aussi.
A votre avis, l'utilisation de politiques peut elle être une solution pour limiter l'héritage.

---

Pour moi non. En tout cas ce n'est pas une alternative équivalente. Une fois que tu as viré la classe de base, tu ne peux plus mettre tes animaux dans le même conteneur. Tu ne peux plus te servir que du polymorphisme statique, somme toute limité. Le remplacement de l'un par l'autre n'est généralement pas une option.

Citation:

---

Envoyé par Mongaulois

- Complexité de compréhension pour une personne tierce
- Fait peur à un client
- Debuggage plus complexe
- Difficulté de remodulation du code si besoin

---

C'est marrant mais dans ma boîte, c'est plutôt les classes de politiques et les templates qui répondraient aux trois premiers points.

Au passage, un moyen de faire du sealing (empecher la possibilitée d'heritage d'une classe) est décrit dans cet article :
http://www.gamedev.net/reference/pro...tures/cppseal/

Personnellement, je trouve que faire en sorte que ce soit difficile (et induire chez l'utilisateur l'idée que c'est certainement inaproprié) est largement suffisant.

Avec :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

template < class T > class SealedBase { protected: SealedBase() { } };   #define Sealed(_CLASS_NAME_) private virtual SealedBase<_CLASS_NAME_>   class Penguin : Sealed(Penguin) { };

---

il suffit d'écrire :

Code:

---

1 2 3 4 5 6 7 8

class BigZ : Penguin, Sealed(Penguin) { };   int main() { BigZ test; }

---

Pour que son astuce ne marche pas mieux que la premiere :p

Et pour la deuxieme astuce (compilo M$) j'écris :

Code:

---

1 2 3

class BigZ : Penguin, private virtual SealedBase<__COUNTER__-1> { };

---

Je te l'avoue, c'est tordu mais...

Se servir de __COUNTER__ de cette manière est dangereux: supposons que la classe Penguin soit définie dans Penguin.h et que je définisse une autre classe Rotweiller dans Rotweiller.h. Si dans un cpp je fais un include de Penguin.h puis Rotweiller.h, __COUNTER__ vaudra respectivement N et N+1. Si dans un autre cpp j'inclus d'abord Rotweiller.h puis Penguin.h, les valeurs de __COUNTER__ ne seront plus les même. Au final, j'obtient plusieurs déclarations et définitions des classes sus-citées - ce qui provoque une phénomène du type "attention à la marche, oups, trop tard" au niveau du code... :)