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
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 ) 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++
A méditer: La solution la plus simple est toujours la moins compliquée
Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
Compiler Gcc sous windows avec MinGW
Coder efficacement en C++ : dans les bacs le 17 février 2014
mon tout nouveau blog
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é
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èresPourquoi de pas plustôt utiliser des class poltique ?
C'est "Advenced C++", qui est l'un des bouquins de la même veine que (more) effective C++ et consorsps :C'est quoi Ac++?
A méditer: La solution la plus simple est toujours la moins compliquée
Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
Compiler Gcc sous windows avec MinGW
Coder efficacement en C++ : dans les bacs le 17 février 2014
mon tout nouveau blog
Mon blog anglais - Mes articles et critiques de livres - FAQ C++0x, avec liste des nouveautés - Conseils sur le C++ - La meilleure FAQ du monde - Avant de créer des classes que vous réutiliserez, regardez si ça n'existe pas déjà - Le site du comité de normalisation du C++
Le guide pour bien débuter en C++ - Cours et tutoriels pour apprendre C++
Blog|FAQ C++|FAQ fclc++|FAQ Comeau|FAQ C++lite|FAQ BS|Bons livres sur le C++
Les MP ne sont pas une hotline. Je ne réponds à aucune question technique par le biais de ce média. Et de toutes façons, ma BAL sur dvpz est pleine...
parchiderme ( 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....
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.
« L'effort par lequel toute chose tend à persévérer dans son être n'est rien de plus que l'essence actuelle de cette chose. »
Spinoza — Éthique III, Proposition VII
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 )
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 : 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
A méditer: La solution la plus simple est toujours la moins compliquée
Ce qui se conçoit bien s'énonce clairement, et les mots pour le dire vous viennent aisément. Nicolas Boileau
Compiler Gcc sous windows avec MinGW
Coder efficacement en C++ : dans les bacs le 17 février 2014
mon tout nouveau blog
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"):
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.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.
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:
C'est l'une des simplfication de l'énoncé du principe de substitution de Liskov.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.
2) l'explication:
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 ?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.
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).
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.
Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
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.
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.
Code : Sélectionner tout - Visualiser dans une fenêtre à part 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 ;)
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
Au final, ce genre d'ouvrage propose des règles, mais sans expliquer la théorie correctement.
+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.
[FAQ des forums][FAQ Développement 2D, 3D et Jeux][Si vous ne savez pas ou vous en êtes...]
Essayez d'écrire clairement (c'est à dire avec des mots français complets). SMS est votre ennemi.
Evitez les arguments inutiles - DirectMachin vs. OpenTruc ou G++ vs. Café. C'est dépassé tout ça.
Et si vous êtes sages, vous aurez peut être vous aussi la chance de passer à la télé. Ou pas.
Ce site contient un forum d'entraide gratuit. Il ne s'use que si l'on ne s'en sert pas.
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
(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 ?
"Never use brute force in fighting an exponential." (Andrei Alexandrescu)
Mes articles dont Conseils divers sur le C++
Une très bonne doc sur le C++ (en) Why linux is better (fr)
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager