Discussion :

[koala01]

De manière générale, l'héritage multiple est peu utilisé, car... peu utile.

Mais, quand tu en a besoin, tu n'a souvent pas d'autres solution

C'est, là encore, comme beaucoup d'autres concepts, parfois plus généraux (je pense, entre autres, aux fonctions récursives): il faut être particulièrement prudent lorsque l'on décide de recourir au concept en cela qu'il faut y recourir quand en connaissance de cause (il ne sert strictement à rien de créer une fonction récursive qui calcule la factorielle d'un nombre, par exemple), mais, quand il faut y recourir, c'est souvent parce que tu te trouve dans l'impossibilité d'implémenter "facilement" ton besoin par une méthode alternative.

L'héritage multiple et la récursivité font partie de ces concepts que tu ne dois pas utiliser "à tout bout de champs", mais qui, bien souvent, sont utilisés "parce qu'il le fallait bien"

[chaplin]

Quand je parle de particularité C++, je devrais plutôt dire de "mécanimes" d'héritage qu'on ne retrouve pas dans JAVA ou C#.

En cherchant sur Google, j'ai trouvé une autre forme d'héritage: héritage non conforme

J'ai même vu que quelqu'un a pensé aux développeurs C et C++ en trouvant un nouveau successeur: le langage D.

Autant je découvre l'application de certaine "stratégie" d'implémentation comme l'héritage privé, autant je découvre des langages (orientés) objets avec tel ou tel spécificité.

Si LSP s'avère être méthode partielle pour ne pas justifié l'héritage puisque l'héritage privé peut forcé le point de vue dans certain cas, je m'apperçois qu'il faut avoir pas mal de règle "objet" en tête pour aborder la conception orienté objet même si certaines reflexions s'appuient sur le bon sens.

[white_tentacle]

Ce n'est pas la plupart des langages, essentiellement un qui a voulu simplifier les choses, et ceux qui s'en sont inspirés.
Eiffel supporte très bien l'héritage multiple -- je ne sais plus s'il dispose d'un héritage d'importation de code. Ruby supporte l'importation de code, indépendamment de l'héritage orienté substituabilité.

En fait, ce n'est pas tout à fait vrai. Eiffel supporte l'héritage multiple, et avec tous les problèmes qui vont avec (qui sont réels). Il y a eu de nombreuses discutions là-dessus (notamment, voir les archives de la ml de smarteiffel (en anglais, désolé)), et smarteiffel a introduit (ou repris ?) le principe de "non-conforming inheritance", ("héritage non conformant" ? je ne sais pas s'il y a une traduction "officielle"), et qui ressemble, sans y être identique, à l'héritage private de c++ (dans le sens où celui-ci n'est, lui non plus, pas "conformant").

Concernant le GC, c'est faux de dire que C++ n'est pas garbage collecté (tout dépend de l'allocateur mémoire utilisé ! encore une fois, une histoire de choix de l'utilisateur, non du concepteur du langage), et je rajouterai à ça une citation (probablement approximative, ma mémoire me faisant défaut) de Stroustrup : "C++ is the best garbage collected language, because it produces little garbage".

[Matthieu Brucher]

Réutiliser la fonction du calcul d'aire du rectangle pour un carré c'est tout l'intérêt du truc.

Je suis désolé, mais pour moi, le calcul de l'aire du carré n'est pas la même que celle du rectangle.

[Matthieu Brucher]

Est ce que l'héritage privé est une pratique courante, parce c'est tout de même une particularité dans C++ comme l'héritage multiple.

Ce que je n'arrive pas à comprendre, pourquoi la plupart des langages supportent que l'héritage simple, qu'ils ont pas d'héritage privé.

Parce que si c'est pour éviter de réécrire du code, mieux vaut la composition.

[Luc Hermitte]

C'est différent. L'un a des avantages et des contraintes que l'autre n'a pas et vice-versa.

[loufoque]

Je suis désolé, mais pour moi, le calcul de l'aire du carré n'est pas la même que celle du rectangle.

Un carré est un rectangle. On peut parfaitement calculer l'aire du carré en ignorant le fait que ce soit un carré et en se restreignant au fait qu'on sait que c'est un rectangle. Ce n'est peut-être pas optimal, mais c'est parfaitement valide.
Largeur * hauteur et cote * cote c'est pareil hein si cote = largeur = hauteur.

[Matthieu Brucher]

Un carré est un rectangle. On peut parfaitement calculer l'aire du carré en ignorant le fait que ce soit un carré et en se restreignant au fait qu'on sait que c'est un rectangle. Ce n'est peut-être pas optimal, mais c'est parfaitement valide.
Largeur * hauteur et cote * cote c'est pareil hein si cote = largeur = hauteur.

Dans ce cas, pourquoi même créer une classe spécifique ?

[bacelar]

Pour pouvoir l'initialiser avec une seule longueur par exemple ?

P.S.: le besoin fait l'outil, donc utilisez un principe quand il vous simplifie la vie, sinon choisissez en un autre (principe).

[koala01]

Dans ce cas, pourquoi même créer une classe spécifique ?

[AvocatDuDiable On]Simplement parce que le carré "réalise" un rectangle spécifique

Une implémentation naïve du constructeur d'un rectangle pourrait parfaitement être

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Rectangle::Rectange(size_t longueur, size_t largeur)

et celle du carré être

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Carre::Carre(size_t cote):Rectangle(cote, cote)

alors que ce serait le seul comportement réellement modifié, car on pourrait envisager le fait que tous les autres comportements attendus pour le carré sont strictement identiques à ceux... d'un rectangle dont les deux cotés sont égaux

ce qui se rapproche finalement très fort de ce que l'on apprend en cours de géométries en primaires

[loufoque]

Dans ce cas, pourquoi même créer une classe spécifique ?

Certains algorithmes s'expriment de manière générique pour tout polygone convexe, par exemple. Tu veux t'amuser à les réecrire pour toutes les figures, qui sont en nombre arbitrairement grand, ou tu préfères avoir une version générique ?

[hegros]

Certains algorithmes s'expriment de manière générique pour tout polygone convexe, par exemple. Tu veux t'amuser à les réecrire pour toutes les figures, qui sont en nombre arbitrairement grand, ou tu préfères avoir une version générique ?

Non tu fais hériter rectangle et carré d'une figure et tu mets dans la figure tes algos génériques. rectangle et carré sont des concepts trop bas dans la hierarchie pour les faire hériter l'un de l'autre.

[HanLee]

C'est, là encore, comme beaucoup d'autres concepts, parfois plus généraux (je pense, entre autres, aux fonctions récursives): il faut être particulièrement prudent lorsque l'on décide de recourir au concept en cela qu'il faut y recourir quand en connaissance de cause (il ne sert strictement à rien de créer une fonction récursive qui calcule la factorielle d'un nombre, par exemple), mais, quand il faut y recourir, c'est souvent parce que tu te trouve dans l'impossibilité d'implémenter "facilement" ton besoin par une méthode alternative.

L'héritage multiple et la récursivité font partie de ces concepts que tu ne dois pas utiliser "à tout bout de champs", mais qui, bien souvent, sont utilisés "parce qu'il le fallait bien"

C'est bien biaisé ça.

Tu devrais aussi dire :
Le style impératif fait partie de ces concepts que tu ne dois pas utiliser à tout bout de champ, mais qui bien souvent sont utilisés parce qu'il le fallait bien.

C'est bien plus facile de se tromper en codant la factorielle en style impératif qu'en style récursif, notamment les problèmes d'indices. En gros toutes les suites récurrentes simples.
Après pour être honnête l'équivalent récursif terminal est aussi ésotérique que la solution impérative.

Pour une liste chaînée classique (style non-STL), le style récursif est excessivement trivial. Et d'un point de vue stylistique, bien plus lisible.

Mais le style non-STL pose alors quelques problèmes, d'un point de vue sémantique...

Voilà, c'est pour dire que : d'une, ça dépend du langage, et d'autre part ça dépend des structures de données utilisées.

Forcément si tu as un langage (comme ici) qui ne promeut pas tel concept, et dont toutes les structures de données se sont adaptés à cette contrainte, le style conseillé sera évidemment biaisé et orienté.

Dans d'autres langages, on dirait que le style impératif est à utiliser avec parcimonie.

----

Un peu comme l'héritage multiple, les langages mainstream excepté C++ ne le supportent pas, on l'enseigne très peu, les gens ne le comprennent pas bien, donc le résultat fait que dans la "conscience collective" on dit "danger", et le manque finit par être compensé par une méthode alternative.
Doit-on dire que l'héritage multiple est peu utile parce qu'on a une méthode alternative qui marche bien ?

J'ai des méthodes A et B qui sont équivalentes en termes de facilité, tout ça. La méthode A qui est la plus utilisée, est utile.
La méthode B est équivalente, donc elle est peu utile ??

[koala01]

C'est bien biaisé ça.

Tu devrais aussi dire :
Le style impératif fait partie de ces concepts que tu ne dois pas utiliser à tout bout de champ, mais qui bien souvent sont utilisés parce qu'il le fallait bien.

C'est bien plus facile de se tromper en codant la factorielle en style impératif qu'en style récursif, notamment les problèmes d'indices. En gros toutes les suites récurrentes simples.
Après pour être honnête l'équivalent récursif terminal est aussi ésotérique que la solution impérative.

Pour une liste chaînée classique (style non-STL), le style récursif est excessivement trivial. Et d'un point de vue stylistique, bien plus lisible.

Mais le style non-STL pose alors quelques problèmes, d'un point de vue sémantique...

Voilà, c'est pour dire que : d'une, ça dépend du langage, et d'autre part ça dépend des structures de données utilisées.

Forcément si tu as un langage (comme ici) qui ne promeut pas tel concept, et dont toutes les structures de données se sont adaptés à cette contrainte, le style conseillé sera évidemment biaisé et orienté.

Dans d'autres langages, on dirait que le style impératif est à utiliser avec parcimonie.

----

Un peu comme l'héritage multiple, les langages mainstream excepté C++ ne le supportent pas, on l'enseigne très peu, les gens ne le comprennent pas bien, donc le résultat fait que dans la "conscience collective" on dit "danger", et le manque finit par être compensé par une méthode alternative.
Doit-on dire que l'héritage multiple est peu utile parce qu'on a une méthode alternative qui marche bien ?

J'ai des méthodes A et B qui sont équivalentes en termes de facilité, tout ça. La méthode A qui est la plus utilisée, est utile.
La méthode B est équivalente, donc elle est peu utile ??

(c'est un peu HS, excusez cette digression)

Si j'ai pris les exemples de la récursivité et de la factorielle, c'est pourtant à dessein:

Une factorielle en version récursive ressemblerait à

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
int factorielle(int value)
{
    if(value==1)
        return 1;
    return value*factorielle(value-1);
}

la version "non récursive" prendrait - quant à elle - la forme de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int factorielle(int value)
{
    int ret = 1;
    for(size_t i=1;i<=value;++i)
        ret*=i;
    return ret;
}

Tu remarque qu'il est - effectivement - possible de définir une fonction récursive pour y arriver, mais qu'à coté de la simple "possibilité" de le faire, son utilisation est de nature à apporter des chutes de performances (l'appel de la fonction a un cout car la fonction ne peut pas être completement inlinée) ou des limitations propres à l'architecture (risque de stack overflow accru).

Dans cette situation il n'est donc "simplement pas opportun" de choisir la récursivité, bien que ce soit "un choix possible".

Par contre, lorsqu'il s'agit de parcourir les noeuds d'un arbre binaire, la solution récursive sera de l'ordre de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
void parcourir(Node* n)
{
    /* ce qui doit être fait pour le noeud en cours */
    if(n->left)
        parcourir(n->left);
    if(n->right)
        parcourir(n->right);
}

et il n'y a que difficilement moyen d'éviter la récursivité: on peut envisager de récupérer les différents noeuds dans d'autres structures, mais, cela a aussi un cout...

C'est la raison pour laquelle j'affirme que c'est une méthode qui vaut la peine d'être utilisée, mais qu'il faut veiller à ne le faire que... quand il le faut (AKA quand les autres possibilités ne sont pas applicables).

Pour en revenir à l'héritage multiple:

Il est clair que c'est une technique - dans l'ensemble - mal comprise et donc synonyme de danger. (la récursivité pose, d'ailleurs, aussi pas mal de problèmes à beaucoup de gens )

Il est clair (comme c'est le cas de la récursivité) que, mal utilisée, cette technique mal utilisée est susceptible de mener à des désastres.

Mais, d'un autre coté, il y a "des cas" dans lesquels cette technique *doit* être préférée à toute autre car il s'agit de "la meilleure des choses à faire"

Maintenant, le fait que d'autres langages n'autorisent pas l'héritage multiple ne prouve qu'une et unique chose: on trouve tout et son contraire en informatique

[HanLee]

Ok, je finis rapidement.
Mon point n'est pas là, tout ce que tu dis est vrai... en C++ à l'heure actuelle.

Tu remarque qu'il est - effectivement - possible de définir une fonction récursive pour y arriver, mais qu'à coté de la simple "possibilité" de le faire, son utilisation est de nature à apporter des chutes de performances (l'appel de la fonction a un cout car la fonction ne peut pas être completement inlinée) ou des limitations propres à l'architecture (risque de stack overflow accru).

Oui, mais je t'ai parlé du cas particulier :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
int factorielle_aux(int value, int accu = 1)
{
    if(value <= 1)
        return accu;
    else
        return factorielle_aux(value-1, value * accu);
}

En activant les optimisations, l'appel à factorielle_aux(n) ça génère du code identique à ta version itérative.

Et dans d'autres langages, ceci est une optimisation garantie par la spécification du langage.

C'est pour ça que je dis selon le langage, ton affirmation est injustifiée.

-----

Quand aux problèmes des gens avec la récursivité, ça n'est qu'une question d'éducation. Il y a sur le forum des gens qui ont enseigné, ils savent pourquoi les gens ont du mal, et en s'y prenant bien, ils ont pu expérimenté que ça pouvait passer comme une lettre à la poste.
Après, c'est pas un vrai argument, mais au MIT, on apprend l'algorithmique avec Scheme, ça leur pose pas de problème.

Un autre exemple, dans la très grosse boîte où je fais mon stage, beaucoup de gens n'utilisent pas la STL, parce que ça leur fait peur.
Les templates, tout ça...
Après, en industrialisation, c'est pour des raisons de support des vieux compilateurs...

[loufoque]

Non tu fais hériter rectangle et carré d'une figure et tu mets dans la figure tes algos génériques.

Cette solution est intrusive et ne marche qu'avec les algos unaires. Bien sûr si on doit travailler avec des classes et sans support pour le multi-dispatch, c'est probablement une des seules solutions.
De toutes façons tu n'amènes rien de nouveau là. Je vois pas pourquoi y'a un "Non", c'est exactement la même chose en utilisant la redéfinition plutôt que la surcharge.
Je dirais même que c'est une moins bonne conception aussi parce que ça nécessite d'introduire une classe Figure abstraite qui ne sert à rien.

rectangle et carré sont des concepts trop bas dans la hierarchie pour les faire hériter l'un de l'autre.

Là par contre, c'est n'importe quoi...

[hegros]

Cette solution est intrusive et ne marche qu'avec les algos unaires. Bien sûr si on doit travailler avec des classes et sans support pour le multi-dispatch, c'est probablement une des seules solutions.
De toutes façons tu n'amènes rien de nouveau là. Je vois pas pourquoi y'a un "Non", c'est exactement la même chose en utilisant la redéfinition plutôt que la surcharge.
Je dirais même que c'est une moins bonne conception aussi parce que ça nécessite d'introduire une classe Figure abstraite qui ne sert à rien.

C'est une vision d'esprit tes algos génériques et toute la science que tu nous sors là. En plus ta version générique tu seras le seul à l'utiliser en laboratoire ou alors à impressionner quelques étudiants roublards, qui est-ce qui en a quelque chose à faire de tes algos génériques sur les carres, les rectangles et les figures ou même de LSP ? LSP n'invente rien du tout tu fais une enquete en entreprise je suis persuadé qu'on frise les 1% d'utilisation donc c'est bien mais on s'en sert pas quand on travaille

Là par contre, c'est n'importe quoi...

Oui c'est cela tu me dis qu'un carre est un rectangle particulier ce que je te dis c'est qu'il n'y a RIEN d'intéressant à ce niveau là à faire en OO sans introduire des concepts plus abstraits comme une figure. Le cas du carre qui hérite du rectangle on a vu ce que cela apporte comme forte valeur ajoutée à savoir rien.

[Matthieu Brucher]

Certains algorithmes s'expriment de manière générique pour tout polygone convexe, par exemple. Tu veux t'amuser à les réecrire pour toutes les figures, qui sont en nombre arbitrairement grand, ou tu préfères avoir une version générique ?

Oui, c'est vrai que pour calculer la surface d'un carré, il vaut mieux prendre la formulation générique pour un polygone quelconque...

[loufoque]

Oui, c'est vrai que pour calculer la surface d'un carré, il vaut mieux prendre la formulation générique pour un polygone quelconque...

La chose étant que y'a des centaines de cas particuliers, tu veux tous les spécialiser ? Tu seras forcément plus performant avec le cas le plus spécialisé, bien entendu, mais des fois tu veux juste un algorithme qui marche de manière performante pour les cas principaux, et qui marche aussi pour les autres cas qui se réduisent à ceux-là.

Apparemment, ce que vous comprenez pas, c'est que la redéfinition d'une méthode (fonction membre virtuelle) c'est du polymorphisme ad-hoc dynamique avec single-dispatch.
La surcharge de fonction, c'est du polymorphisme ad-hoc statique avec multiple-dispatch.
Les multi-méthodes (non disponibles en C++), c'est du polymorphisme ad-hoc dynamique avec multiple-dispatch.

Donc tout ça, c'est la même chose. Le polymorphisme ad-hoc c'est l'idée de faire varier le comportement d'une fonction en fonction de ses arguments.

Typiquement, si je veux faire un algorithme générique qui me dit si une figure est complètement dans une autre, j'ai besoin de multiple-dispatch, parce que la bonne version de l'algorithme à appeler dépend des types des deux arguments.
La redéfinition de méthode ne peut chercher la version qu'à partir d'un seul argument, à moins de coupler ça à la surcharge ce qui en fait un système bancal dynamique/statique, autant tout faire avec celle-ci.