Discussion :

[oodini]

Il n'en reste pas moins que si tu le slice tu te retrouves avec un objet inutile...
EDIT: et c'est l'hypothèse optimiste, parce qu'utiliser un objet avec des comportements de sa classe de base peut amener des bugs laids et difficiles à comprendre

Mais pourquoi une classe dérivée devrait-elle forcément redéfinir les comportement de ses classes parentes ?
Si j'ai une classe parente Voiture, on peut imaginer qu'elle ait un membre et un accesseur concernant la couleur, et il n'y a pas forcément de raison que cela soit redéfini dans les classes parentes. Si l'accesseur est la seule méthode publique de cette classe parente, et qu'on ne s'intéresse, à un moment donné, qu'à la couleur, pourquoi se trimballerait-on avec des objets complets plutôt qu'avec des objets de base, plus légers ? Cela permettrait en outre d'empêcher l'utilisateur d'accéder à des membres publics des classes dérivées.

[therwald]

C'est possible. Cependant dans ce cas une composition marche aussi bien. Pas mal de gens s'attendent à ce que l'héritage signifie comportement différent en fonction des sous-types. En faisant autrement tu tends des chausses trappes à d'autres personnes qui voudraient modifier ton code.

[Flob90]

Si tu t'interesse à la couleur, alors pourquoi retourner un objet qui ne représente qu'un bout du vrai objet sans aucun sens à la place de retourner juste la couleur qui a un sens bien précis ?

Et ton raisonnement est sur les données, pas sur les services que doivent fournir tes classes, quand on parle de OO c'est pas une bonne idée (oublie qu'il y a des données et la notion d'accesseur, les principes OO n'en tiennent pas compte).

NB: Ce qu'on "trimballe" ce sont des pointeurs/références sur les dit objets, le coût est dans bien des cas surment plus faible que de créer un objet du type parent (sauf si on détruit l'objet de type enfant, mais dans ce cas pourquoi l'avoir créé ?).

PS: Tu peux d'ailleurs noté que ios_base interdit la copie.

Edit: A moins que tu lui donnes les moyens de caster vers le type réel, l'utilisateur ne pourra pas utiliser les membres du type dérivé (et quand bien même i le ferait, cet objet offre bien ces services, enquoi ce serait une erreur de les utiliser ? si ils n'ont pas de sens pour cet objet alors pourquoi avoir choisit ce type pour cet objet ?).

[oodini]

C'est possible. Cependant dans ce cas une composition marche aussi bien.

Certes, mais pas mieux.
En gros, tu es train de dire que tout ce qui n'est pas polymorphique doit être évacué de la hiérarchie.

Pas mal de gens s'attendent à ce que l'héritage signifie comportement différent en fonction des sous-types.

C'est peut-être là le problème. Rien dans le C++ ne dit que l'héritage ne doit être utilisé qu'à cela. Et même si c'était le cas, rien ne dirait que tous les comportements devraient différer en fonction des sous-types.

En faisant autrement tu tends des chausses trappes à d'autres personnes qui voudraient modifier ton code.

Non. C'est eux qui se tendent des chausses-trappes en se posant des vues trop restrictives sur la conception de code, et en en évacuant d'autres pourtant valides.

[therwald]

PS: Tu peux d'ailleurs noté que ios_base interdit la copie.

A ce propos est-ce que ce n'est pas un peu un cas "implémentation en terme de"?
On a en une seule classe de l'interface et une base d'implémentation, non?
(c'est une vraie question)

En ce qui concerne le cas du PO, pour avoir vu un autre post où il parle de créer celui-ci, je pense qu'en fait il veut faire une factory method, et que dans son cas le slicing va lui causer des ennuis...

[jblecanard]

Une autre fonction pourrait avoir ces besoin, mais pas celle-ci.

Je veux bien un exemple pertinent.

On pourrait avoir un vecteur d'objet de type enfantA. On va en récupérer un, puis on va le rebalancer en sortie de la fonction comme un objet de type base, parce que l'appelant n'a pas besoin de savoir de quel type dérivé il s'agit.

En effet, il n'a pas besoin de le savoir, mais si tu lui donnes un pointeur sur le type de base, non seulement il ne le sait pas, le LSP est respecté et enfin, la cohérence d'exécution en fonction du type réel est respectée. Si tu tronques ton objet : quel bénéfice en retires-tu par rapport à la technique correcte de l'usage d'un pointeur ?

Quand tu utilises une fonction qui te renvoie une instance d'un objet de base, et non pas un pointeur, pourquoi t'attendrais-tu donc à un comportement défini dans des classes dérivées ??

Parce que c'est la raison pour laquelle un héritage public a été créé. Si ce n'est pas le cas, ton design est boiteux et tes classes ont plusieurs responsabilités à la fois. Si tu es intimement persuadé que l'héritage peut avoir une autre utilité et être utilisé autrement, soit, mais peux-tu nous donner un exemple précis et pertinent ?

Cela n'est gênant que lorsque la hiérarchie repose effectivement sur le polymorphisme. Mais ce n'est pas toujours le cas. Si aucune fonction n'est déclarée en virtuel, je ne vois pas en quoi le slicing peut poser problème.

Parce que ça veut dire que ton code va se comporter différemment en fonction du fait qu'il y ai des fonctions virtuelles ou non. Que fais-tu le jour où tu fais évoluer ton code et que tu ajoutes de la virtualité ? Tu réécris tout le soft ?
Avec un pointeur, fonctions virtuelles ou non, le code restera correct.

Le seul exemple utile que je connaisse de hiérarchie de classe sans surcharge de fonction virtuelle pourrait être l'usage d'un super-objet comme dans certains frameworks. Et dans ce cas, on utilise encore une fois une sémantique d'entité. Tronquer un objet qui a une sémantique d'entité n'a aucun sens logique.

Je comprend bien ta démarche de ne pas vouloir accepter les dogmes par défaut oodini (et elle est louable), mais là, ce n'est pas un dogme, on te fournit toutes les explications pour lesquelles faire un mix ignoble entre sémantique d'entité et de valeur est dangereux pour ton code. Pourquoi persister à croire le contraire sans arguments et sans exemples pertinents ?

Tout cela est expliqué dans la FAQ. Si tu n'es toujours pas convaincu, lis donc les travaux de Mme Liskov.

[Flob90]

Rien dans le C++ ne dit que l'héritage ne doit être utilisé qu'à cela.

Qu'entends tu par "dans le C++" ? Si tu considères juste la norme, alors en effet non ce n'est pas le cas. Si tu considères l'ensemble de la littérature C++ (disons l'ensemble des ouvrage C++ de chez Addison-Wesley), alors si, le C++ le dit (*) (**).

Tu ne trouve pas qu'il y a un problème de conception quand tu décides de ne retourner qu'une partie d'un objet qui a un sens bien précis ? Si l'objectif est de réduire l'ensemble des caractéristiques de cet objet, alors tu devrais retourner un objet d'un autre type représentant cet ensemble de caractéristiques. Là c'est comme si tu retournais cet ensemble et un ensemble de service qui va "bien avec" (ie l'ensemble des services qui définissent ces caractéristiques).

Pour reprendre les voitures, c'est comme si tu avais une classe fille VoitureDeSport, que tu prenais juste les caractéristiques "vitesse" et "poids" et qu'avec ca tu créais une nouvelle voiture qui a ce poids et cette vitesse (ie dont les services caractérisant le poids et la vitesse ont des comportements compatible avec ce poids et cette vitesse). Le problème c'est qu cette nouvelle voiture n'a aucun sens (ce n'est ni une voiture de sport, ni une simple voiture). Et en conception objet, quand tu te retrouves avc quelque chose qui n'a aucun sens c'est assez mauvais.

@therwald: J'ai pas regardé en détails, je ne sais pas pourquoi l'architecture de la partie IO de la bibliothèque standard est comme ca, ni si c'est l'idéal (d'un point de vue conception).

(*) Du moins pour ceux que j'ai lu
(**) Je n'excut pas l'existence de cas où il sert juste pour resoudre un problème purement technique (ie qui n'a rien à voir avec la conception) mais ils doivent rester anecdotique.

[oodini]

Je veux bien un exemple pertinent.

Si je reprend le cas de la voiture cité plus haut, la couleur ne dépend pas de l'implémentation des classes dérivées. L'autonomie, si.

En effet, il n'a pas besoin de le savoir, mais si tu lui donnes un pointeur sur le type de base,

La discussion ne portait pas sur la comparaison entre objet et pointeur, mais entre objet de base et objet dérivé.
Je fais quant à moi rarement des vecteurs d'objets, ne serait-ce que pour des raisons de mémoire.
Mais bon, je réagissais au code présenté, qui ne parlait ni de cette préoccupation, ni de polymorphisme.

non seulement il ne le sait pas, le LSP est respecté et enfin, la cohérence d'exécution en fonction du type réel est respectée. Si tu tronques ton objet : quel bénéfice en retires-tu par rapport à la technique correcte de l'usage d'un pointeur ?

Par rapport à un objet de base : copie d'un objet plus léger
Par rapport à un objet de base et à un pointeur : on n'offre aux utilisateurs que les fonctionnalités offertes par l'objet de base, ce qui peut avoir son intérêt.

Parce que c'est la raison pour laquelle un héritage public a été créé.

Ah bon ? D'où tiens-tu ça ?
On pourrait aussi dire que ça a été créé pour factoriser du code et plus globalement modéliser un apparentement, et des caractéristiques communes (relation "est un(e)").

Si ce n'est pas le cas, ton design est boiteux et tes classes ont plusieurs responsabilités à la fois.

Quel rapport avec la multiresponsabilité ?

Parce que ça veut dire que ton code va se comporter différemment en fonction du fait qu'il y ai des fonctions virtuelles ou non. Que fais-tu le jour où tu fais évoluer ton code et que tu ajoutes de la virtualité ? Tu réécris tout le soft ?
Avec un pointeur, que ce soit le cas ou pas, le code restera correct.

Tout à fait d'accord. Mais tu abordes là un autre problème : la maintenance.
On peut par ailleurs imaginer que la classe de basse, faisant fi des notions d'encapsulation, offre en public des données membre...
Mais nous nous chamaillons sur des spéculations, plutôt que de nous limiter aux éléments qui nous sont donnés par le posteur original.

Je comprend bien ta démarche de ne pas vouloir accepter les dogmes par défaut oodini (et elle est louable), mais là, ce n'est pas un dogme, on te fournit toutes les explications pour lesquelles faire un mix ignoble entre sémantique d'entité est de valeur est dangereux pour ton code.

Je ne perçois pas bien où intervient cette notion de sémantique. On parle d'un seul et unique objet, qu'on voit partiellement ou pas.

Pourquoi persister à croire le contraire sans arguments et sans exemples pertinents ?

Voir ci-dessus.

Je ne dois pas maîtriser le sujet. :-)

[jblecanard]

Mais nous nous chamaillons sur des spéculations, plutôt que de nous limiter aux éléments qui nous sont donnés par le posteur original.

De toute évidence, le posteur original ne maîtrise pas le sujet dont nous discutons. Nous lui donnons donc les outils connus des développeurs actuels pour élaborer un code correct.

Je ne perçois pas bien où intervient cette notion de sémantique. On parle d'un seul et unique objet, qu'on voit partiellement ou pas.

Sans offense aucune, cette citation prouve en effet que tu ne maîtrises pas trop le sujet. Distinguer la sémantique d'entité et la sémantique de valeur est quelque chose d'important.

La FAQ regorge d'excellentes rédactions sur le sujet. Va donc mariner un peu dessus, tu verras, une fois ce travail fait, tu comprendras ce qu'on essaye de te dire avec Flob et les autres.

[oodini]

Qu'entends tu par "dans le C++" ? Si tu considères juste la norme, alors en effet non ce n'est pas le cas. Si tu considères l'ensemble de la littérature C++ (disons l'ensemble des ouvrage C++ de chez Addison-Wesley), alors si, le C++ le dit (*) (**).

Je n'ai pas lu tous les ouvrages de cette collection, mais ai dans ma bibliothèque les Meyers, Alexandrescu, Sutter, Koenig, mais je n'ai pas de souvenir précis concernant ce point. Mais je crois qu'il n'y pas de vérité universelle. Meyers a par exemple une idée particulière de l'encapsulation.

Tu ne trouve pas qu'il y a un problème de conception quand tu décides de ne retourner qu'une partie d'un objet qui a un sens bien précis ?

Un objet n'a pas un sens. Dans la vie de tous les jours, tu ne dis pas qu'un objet a un sens. Une essence, à la limite. Des caractéristiques, donc.
Or, quand tu ton voisin te demandes les caractéristiques de ta nouvelle voiture, tu ne vas pas lui sortir le mode d'emploi, mais plutôt la brochure. Les informations que tu délivres peuvent dépendre du destinataire ou du contexte. On s'autorise bien à utiliser la directive friend pour ouvrir les accès standard, pourquoi pas une autre méthode pour les restreindre ?

Dans l'exemple d'un téléphone, si tu n'as pas le code PIN, tu peux appeler les numéros d'urgence, mais tu n'as pas accès au service standard. Si tu es abonné à une chaîne porno, tes enfants n'auront normalement pas accès à tout tes abonnements s'ils n'ont pas le code parental.

Si l'objectif est de réduire l'ensemble des caractéristiques de cet objet, alors tu devrais retourner un objet d'un autre type représentant cet ensemble de caractéristiques.

C'est ce qui est fait, en fait : on retourne, via le transtypage, une copie d'une partie de l'objet.

Là c'est comme si tu retournais cet ensemble et un ensemble de service qui va "bien avec" (ie l'ensemble des services qui définissent ces caractéristiques).

Pour reprendre les voitures, c'est comme si tu avais une classe fille VoitureDeSport, que tu prenais juste les caractéristiques "vitesse" et "poids" et qu'avec ca tu créais une nouvelle voiture qui a ce poids et cette vitesse (ie dont les services caractérisant le poids et la vitesse ont des comportements compatible avec ce poids et cette vitesse). Le problème c'est qu cette nouvelle voiture n'a aucun sens (ce n'est ni une voiture de sport, ni une simple voiture). Et en conception objet, quand tu te retrouves avec quelque chose qui n'a aucun sens c'est assez mauvais.

A une époque, j'étais en mission chez PSA, dans leur service de réalité virtuelle. L'ensemble de la voiture était modélisé dans CATIA. Inutile de te dire que la base de données était TRÈS lourde. Et que dans le cadre de la RV, nous n'avions de toute façon pas besoin de l'ensemble des données. Nous récupérions donc la carrosserie, les roues, l'habillage intérieur, les informations de matériaux... Bref, tout ce qui était visible.
Et ça avait alors un sens, de ne pas avoir de moteur dans la voiture !
Surtout que PSA ne voulait pas non plus filer les moindres détails de leurs bagnoles à des prestas...

[oodini]

La FAQ regorge d'excellentes rédactions sur le sujet. Va donc mariner un peu dessus, tu verras, une fois ce travail fait, tu comprendras ce qu'on essaye de te dire avec Flob et les autres.

J'en reviens, mais je ne vois pas le rapport avec notre problème.
Je ne vois pas ou intervient la sémantique d'entité, puisqu'on fait une copie.

[therwald]

A une époque, j'étais en mission chez PSA, dans leur service de réalité virtuelle. L'ensemble de la voiture était modélisé dans CATIA. Inutile de te dire que la base de données était TRÈS lourde. Et que dans le cadre de la RV, nous n'avions de toute façon pas besoin de l'ensemble des données. Nous récupérions donc la carrosserie, les roues, l'habillage intérieur, les informations de matériaux... Bref, tout ce qui était visible.
Et ça avait alors un sens, de ne pas avoir de moteur dans la voiture !
Surtout que PSA ne voulait pas non plus filer les moindres détails de leurs bagnoles à des prestas...

A mon sens, dans ce cas, tu n'as pas deux objets lié par une relation "est-un", mais l'objet et un type dinstinct "extrait_public". Les deux ne sont pas interchangeables, ne servent pas à la même chose, donc n'ont pas le même sens. Leur donner une relation d'héritage brouille leur sémantique. C'est mauvais pour la maintenance. Et pour peu que ton dev soit un peu ambitieux, tu peu te retrouver "en mode maintenance" sur certains modules même lors du projet initial.

[jblecanard]

Je te la fais en simple :
- Hiérarchie de classe -> Sémantique d'entité -> Respect du LSP
- Copie d'objets -> sémantique de valeur -> Pas d'héritage
- Mélange de toutes ces notions -> Bordel, code dangereux, pas maintenable

Je comprend ce que tu veux dire par rapport au fait d'avoir une vue réduite d'un objet. Mais utiliser un pointeur sur une des classes parent rempli cet objectif. Si tu fais du slicing, cela signifie que pour utiliser correctement les objets sans dangers, l'utilisateur doit savoir comment c'est implémenté (par exemple savoir s'il y a de la virtualité ou non). Et ça on ne le veux pas, car ça complexifie l'écriture du code et sa maintenabilité.

Ta comparaison sur CATIA est bizarre : il s'agit d'un découpage de données final maîtrisé et choisi par l'utilisateur. Ce n'est pas le cas quand tu tronques des objets, tu ne maîtrises pas le tronquage en fonction de ton besoin.

[Flob90]

Que Meyers, Sutter, Alexandrescu et autres soient en désaccord sur certains points très précis je le concois, cependant je suis presque convaincu qu'ils sont d'accord sur les (5) principes de base de la POO et la facon dont ils (les principes) se retrouvent dans le C++ et amènent à considérer diverses choses, dont en particulier qu'une héritage publique est incompatible avec un consruteur de copie dans le cas général.

Ton exemple avc CATIA est basé sur une base de données, c'est une vision totalement différente des choses. Le design OO a adopté pour traiter des DB est en lui seul un sujet qui peut amener à débat, celui des ORM (Emmanuel Deloget a écrit un billet survolant quelques problèmes intéressant sur le sujet).

C'est ce qui est fait, en fait : on retourne, via le transtypage, une copie d'une partie de l'objet.

Pas vraiment non. Avec ton exemple de couleur, supposons que la classe mère founient 2 services : WhatColor/Draw. Quand tu retournes une partie de l'objet tu retournes quelques chose qui va pouvoir réaliser ses 2 services, mais si je réalise le service Draw, quel est la voiture que je peinds ? Celle d'origne ? Non puisque ce n'est qu'une partie de la voiture. Une nouvelle voiture ? Non plus, puisque cette partie devrait représenter la voiture d'origine.

Alors que si je retourne juste quelque chose de la forme ColorType (type de retou de WhatColor par exemple), là j'ai bien un objet (hors e ma hiérarchie) qui représente la couleur de ma voiture. Et pas un morceau de voiture tombé du ciel.

[Jean-Marc.Bourguet]

Que Meyers, Sutter, Alexandrescu et autres soient en désaccord sur certains points très précis je le concois, cependant je suis presque convaincu qu'ils sont d'accord sur les (5) principes de base de la POO et la facon dont ils (les principes) se retrouvent dans le C++ et amènent à considérer diverses choses, dont en particulier qu'une héritage publique est incompatible avec un consruteur de copie dans le cas général.

Le passage de concept OO vers concept C++ est clair. Ce qui n'est pas clair du tout est qu'un concept C++ ne devrait être utilisé que pour le concept OO qui peut lui être associé. On a quand même pas mal de techniques qui ne sont pas très OO dans l'utilisation des fonctionalités prévues principalement pour implémenter les concepts OO (une classe dont on ne dérive qu'une fois par construction, c'est pas OO, mais c'est ce qu'on fait avec le CRTP).

Pour moi, si la présence simultanée d'héritage et d'un constructeur de copie est souvent symptome d'un problème, ce n'est pas parce que ça contrevient aux principes OO (le constructeur de copie sans héritage contrevient aux principes OO qui ne convient bien qu'à un monde d'entités et pas bien du tout à un monde de valeurs), c'est parce qu'il n'y a pas d'utilisation courante (OO ou non).

[Jean-Marc.Bourguet]

Je ne vois pas ou intervient la sémantique d'entité, puisqu'on fait une copie.

Un entité a un état qui lui est souvent une valeur (souvent, car quand l'entité entretient une relation étroite avec des éléments extérieurs -- fichiers, mutex -- l'aspect valeur peut ne plus être très clair).

Si on a à manipuler les deux, n'utiliser qu'un seul type est tentant et gérable. Mais il faut rester conscient qu'on donne deux objectifs différents à la même classe, ce qui fini souvent par causer des problèmes; au minimun de clarté d'intention.

[therwald]

Par ailleurs on s'est tous enflammés sur notre débat, mais le titre de la thread étant "héritage et polymorphisme info", je pense que le PO souhaite bénéficier de comportements polymorphes...ce qui règle la question concernant le code qu'il a fourni: il est faux car en slicant il perd le bénéfice de sa polymorphie.
Il faut qu'il retourne une référence ou un smart pointer, en fonction de qui gère la durée de vie de l'instance utilisée.

[Flob90]

Ce qui n'est pas clair du tout est qu'un concept C++ ne devrait être utilisé que pour le concept OO qui peut lui être associé. On a quand même pas mal de techniques qui ne sont pas très OO dans l'utilisation des fonctionalités prévues principalement pour implémenter les concepts OO

Oui, je suis d'accord, c'était un peu ce que je voulais dire par "en général" et dans l'anotation (**) d'un message précédent. Même si sur le moment je ne vois pas ce qui pourrait amener un tel besoin (copy-ctor + héritage publique), il pourrait apparaitre, mais ne serait probablement pas lié à la partie "design OO" de l'application (mais utilisé pour résoudre autre chose : un problème technique spécifique, profiter d'un comportement du langage pour "simplifier" une opération, profiter d'un "hack", ...).

Pour moi, si la présence simultanée d'héritage et d'un constructeur de copie est souvent symptome d'un problème, ce n'est pas parce que ça contrevient aux principes OO (le constructeur de copie sans héritage contrevient aux principes OO qui ne convient bien qu'à un monde d'entités et pas bien du tout à un monde de valeurs), c'est parce qu'il n'y a pas d'utilisation courante (OO ou non).

Je ne comprends pas bien ce que tu veux dire dans ta parenthèse.

D'un point de vue OO, un héritage va symboliser une sémantique d'entité, la mise en place d'un copy-ctor va permettre la création d'entités de cette hiérarchie à partir d'entités plus spécialisés. On va donc pouvoir copier une entité spécifique en perdant sa spécificité, ce n'est donc plus une copie. On ne peut pas voir ca comme une faiblesse du design OO : on attend une copie et on obtient moins que ca ? (Même si ce n'est pas lié directement aux principes de l'OO) (C'est une vrai question)

[Jean-Marc.Bourguet]

Je ne comprends pas bien ce que tu veux dire dans ta parenthèse.

Tout l'OO tourne autour d'une semantique d'entite et non de valeur. La notion OO la plus proche d'une valeur est une entite immuable, ce qui n'est pas tout a fait la meme chose (on teste plus facilement l'identite -- qui n'a pas reellement de sens -- que l'egalite par exemple). C'est tellement vrai que les langages OO ont souvent un support un peu different pour les types de bases qui n'est pas extensibles aux types definis par l'utilisateur.

[jblecanard]

Par ailleurs on s'est tous enflammés sur notre débat, mais le titre de la thread étant "héritage et polymorphisme info", je pense que le PO souhaite bénéficier de comportements polymorphes...ce qui règle la question concernant le code qu'il a fourni: il est faux car en slicant il perd le bénéfice de sa polymorphie.
Il faut qu'il retourne une référence ou un smart pointer, en fonction de qui gère la durée de vie de l'instance utilisée.

C'est ce qu'on dit depuis le début, [joke]c'est encore oodini qui a fait le rebelle et semé la pagaille dans la république [/joke]