Discussion :

[oodini]

Hello,

Un mammifère est-il un vertébré, ou est-il construit (= implémenté) à l'aide de vertèbres ?

Héritage ou composition ?

Voilà les questions qui ressurgissent quand un codeur C++ passe au C# où l'héritage multiple n'est pas autorisé...

[hegros]

Et pourquoi pas les 2 ? Sachant que vertébré et vertèbre sont 2 concepts différents où l'un est une classification et l'autre c'est des os.

Je ne vois pas trop le problème de l'héritage multiple et comment tu souhaites l'utiliser..

Ci-joint un diagramme

[bruno_pages]

Un mammifère est-il un vertébré, ou est-il construit (= implémenté) à l'aide de vertèbres ?

Héritage ou composition ?

est-un vertébré est un héritage

à des vertèbres est une agrégation, pas une composition car pour le plus grand bonheur des paléontologues les vertèbres existent par elles-mêmes

Voilà les questions qui ressurgissent quand un codeur C++ passe au C# où l'héritage multiple n'est pas autorisé...

idem pour Java

oui, le manque d'héritage multiple est une aberration liée à la fainéantise des personnes ayant fait Java, et à la recopie qui en a été faite par C#

mais qu'elle était la question ?

[oodini]

Et pourquoi pas les 2 ? Sachant que vertébré et vertèbre sont 2 concepts différents où l'un est une classification et l'autre c'est des os.

Oui, effectivement, les deux sont possibles. Mais l'un impliquant l'autre, je mettais de côté la configuration que tu présentes.

Je ne vois pas trop le problème de l'héritage multiple et comment tu souhaites l'utiliser...

Prenons un autre exemple : les oiseaux.

Comment dire que les oiseaux sont à la fois des vertébrés et des ovipares ? Sans héritage multiple ?

[oodini]

à des vertèbres est une agrégation, pas une composition car pour le plus grand bonheur des paléontologues les vertèbres existent par elles-mêmes

D'un autre coté, elles ne peuvent être liées qu'à une seule instance, et ne peuvent être créées en dehors d'elle.
Comment modéliser cela en UML, tiens ?

oui, le manque d'héritage multiple est une aberration liée à la fainéantise des personnes ayant fait Java, et à la recopie qui en a été faite par C#

mais qu'elle était la question ?

Voir ma réponse précédente. :-)

[hegros]

Oui, effectivement, les deux sont possibles. Mais l'un impliquant l'autre, je mettais de côté la configuration que tu présentes.

Je ne comprends pas, il y a 2 concepts différents c'est normal d'avoir un héritage et une agrégation..

Prenons un autre exemple : les oiseaux.

Comment dire que les oiseaux sont à la fois des vertébrés et des ovipares ? Sans héritage multiple ?

Je parlais pour le problème que tu exposais ne voyant pas d'héritage multiple à l'horizon sinon on peut résoudre cela avec de la composition en s'abstenant d'utiliser des interfaces.

Pour ma part j'ai jamais vraiment eu besoin d'utiliser l'héritage multiple sachant qu'il y a toujours des alternatives qui niveau design sont moins compliqué et plus évolutive

Ci-joint ce diagramme

[oodini]

Pour ma part j'ai jamais vraiment eu besoin d'utiliser l'héritage multiple sachant qu'il y a toujours des alternatives qui niveau design sont moins compliqué et plus évolutive

Peut-être parce que tu n'as pas vraiment eu l'occasion de travailler dans un langage qui permet l'héritage multiple, et que tu as inconsciemment intégré des stratégies d'évitement.

Concernant ton diagramme UML, si tu as plusieurs hiérarchies (taxonomie, stratégie de reproduction, catégorie ambulatoire...). Pour chacune des combinaisons (par ex. vertébré, ovipare, quadrupède), tu devras créer une classe un peu fictive. Ou alors créer une classe sur doté de nombreuses compositions, dont certaines seront éventuellement "débranchées" (certains vertébrés ovipares, comme les serpents, n'ont pas de membres locomoteurs).

[hegros]

Peut-être parce que tu n'as pas vraiment eu l'occasion de travailler dans un langage qui permet l'héritage multiple, et que tu as inconsciemment intégré des stratégies d'évitement.

Je pourrais dire la même chose de ceux qui n'ont travaillé qu'avec des langages qui permettent l'héritage multiple : ils se sont habitués à placer coûte que coûte de l'héritage multiple partout alors que la composition est une façon élégante de faire la même chose les problèmes de design en moins.

Et l'héritage multiple ce n'est qu'une solution technique et un détail d'implémentation, on peut avoir un modèle juste et cohérent sans héritage multiple

Concernant ton diagramme UML, si tu as plusieurs hiérarchies (taxonomie, stratégie de reproduction, catégorie ambulatoire...). Pour chacune des combinaisons (par ex. vertébré, ovipare, quadrupède), tu devras créer une classe un peu fictive. Ou alors créer une classe sur doté de nombreuses compositions, dont certaines seront éventuellement "débranchées" (certains vertébrés ovipares, comme les serpents, n'ont pas de membres locomoteurs).

Peut-être pas et ce n'est pas vraiment dérangeant que certaines compositions (traduites par des collections) soient vides. Et je ne vois toujours pas en quoi l'héritage multiple simplifie quelque chose à cela et améliore le design.

Si tu y tiens vraiment alors utilises des interfaces, cela revient un peu au même (cela revient à faire de la composition en fait) avec l'aspect 'natif' en moins qui apporte dans 80% des cas j'en suis persuadé rien du tout.

[oodini]

Je pourrais dire la même chose de ceux qui n'ont travaillé qu'avec des langages qui permettent l'héritage multiple : ils se sont habitués à placer coûte que coûte de l'héritage multiple partout alors que la composition est une façon élégante de faire la même chose les problèmes de design en moins.

Non, tu te trompes. EN C++, on n'utilise pas souvent l'héritage multiple. Mais on le fait quand c'est nécessaire. Et si la composition est techniquement toujours faisable, elle n'est pas toujours élégante, loin de là.
La composition signifie "est composé de". Cela n'est pas applicable à la nature ovipare ou vivipare d'un animal. À moins de passer par une classe fourre-tout de propriétés.

Et l'héritage multiple ce n'est qu'une solution technique et un détail d'implémentation, on peut avoir un modèle juste et cohérent sans héritage multiple

L'héritage, simple ou multiple, est une modélisation. Il est supposé être le moins contraint possible par l'implémentation utilisée.

Peut-être pas et ce n'est pas vraiment dérangeant que certaines compositions (traduites par des collections) soient vides.

Ce n'est pas juste et cohérent. Un serpent n'a pas à avoir une propriété sur son nombre de membres locomoteurs. Ça ne le concerne pas.

Et je ne vois toujours pas en quoi l'héritage multiple simplifie quelque chose à cela et améliore le design.

Dommage pour toi.

Si tu y tiens vraiment alors utilises des interfaces, cela revient un peu au même (cela revient à faire de la composition en fait) avec l'aspect 'natif' en moins qui apporte dans 80% des cas j'en suis persuadé rien du tout.

El l'occurrence, j'ai surtout besoin d'attributs. Donc, les interfaces...

Cela dit, j'apprécie tes interventions, car elles me donnent des solutions.
Il est simplement dommage que tu apparaisses aussi dogmatique quant à l'héritage multiple...

[hegros]

Non, tu te trompes. EN C++, on n'utilise pas souvent l'héritage multiple.

Cela montre bien son intérêt

La composition signifie "est composé de".

La composition ce n'est pas que cela, on l'utilise dans de nombreux pattern de conception.

Ce n'est pas juste et cohérent. Un serpent n'a pas à avoir une propriété sur son nombre de membres locomoteurs. Ça ne le concerne pas.

Mais là c'est toi qui voit des attributs où il ne devrait pas en y avoir. S'il n'a pas de propriété locomoteur beh tu n'en mets pas

Dommage pour toi.

C'est d'autant plus dommage pour toi que tu ne sois pas en mesure de l'expliquer pour ton cas précis en donnant un exemple en C++ si cela t'enchante. Parce que ce que tu sembles vouloir modéliser, et au vu de la complexité, ne rendra pas les choses plus facile avec de l'héritage multiple

[oodini]

Cela montre bien son intérêt

Ben c'est intéressant quand on en a besoin ! Comme les pointeurs.

La composition ce n'est pas que cela, on l'utilise dans de nombreux pattern de conception.

Certes, mais ce sont des détails d'implémentation. Dans ce cas, on fait ce qu'on veut. Mais quand tu parles de classes qui ont une vraie signification métier, il faut modéliser correctement, dans la mesure du possible, la vraie nature des choses.

Mais là c'est toi qui voit des attributs où il ne devrait pas en y avoir. S'il n'a pas de propriété locomoteur beh tu n'en mets pas

J'ai cru comprendre que tu mettrais cela dans la classe Classification, non ?

C'est d'autant plus dommage pour toi que tu ne sois pas en mesure de l'expliquer pour ton cas précis en donnant un exemple en C++ si cela t'enchante. Parce que ce que tu sembles vouloir modéliser, et au vu de la complexité, ne rendra pas les choses plus facile avec de l'héritage multiple

Certains animaux ont des pattes, mais pas tous.
Certains animaux sont des vertébrés, mais pas tous.
En l'absence d'héritage multiple, tu dois te trimballer des attributs éventuellement non initialisés, ou des booléens, ou que sais-je. Pas de problèmes pour un codeur, mais un serpent n'est pas un animal à pattes dont les pattes n'ont pas poussé.

[hegros]

Certes, mais ce sont des détails d'implémentation. Dans ce cas, on fait ce qu'on veut. Mais quand tu parles de classes qui ont une vraie signification métier, il faut modéliser correctement, dans la mesure du possible, la vraie nature des choses.

Oui et on peut modéliser de plusieurs manières un héritage multiple. En utilisant par exemple des abstractions et de simples agrégations négociant quelques contraintes ocl.

J'ai cru comprendre que tu mettrais cela dans la classe Classification, non ?

Non Classification c'est juste une classe abstraite improvisée probablement vide d'attribut si ce n'est un nom, je ne suis pas un paléontologue mais je créerais à priori une classe Locomoteur (qui hériterait de classification) qui est un concept à part entière.

Certains animaux ont des pattes, mais pas tous.
Certains animaux sont des vertébrés, mais pas tous.
En l'absence d'héritage multiple, tu dois te trimballer des attributs éventuellement non initialisés, ou des booléens, ou que sais-je. Pas de problèmes pour un codeur, mais un serpent n'est pas un animal à pattes dont les pattes n'ont pas poussé.

Le problème avec ce genre d'énoncé c'est que l'on va à priori se retrouver à faire un héritage de 10 ou 100 classes tellement il existe de classification. Parce que dans cet énoncé à priori le serpent n'hérite que d'une classe qui est celle des vertébrés. Pour l'oiseau c'est effectivement tentant de faire un héritage multiple

En tout cas avec des interfaces cela n'apporterait pas moins que l'héritage multiple à priori. Cela y ressemblerait même beaucoup.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

interface IEspeceVertebré
{
   void UneMethodeEspeceVertebré();
}

interface IEspeceAvecPatte
{
   void UneMethodeEspeceAvecPatte();
}

class Serpent : IEspeceVertebré
{
   void UneMethodeEspeceVertebré(){}
}

class Oiseau : IEspeceVertebré, IEspeceAvecPatte 
{
   void UneMethodeEspeceVertebré(){}
   void UneMethodeEspeceAvecPatte(){}
}

Après pour on peut toujours créer de pure fabrication une classe Vertebré pour le comportement commun et utiliser pour le coup la délégation dont on parle depuis tout à l'heure

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
class EspeceVertebré : IEspeceVertebré 
{
   void UneMethodeEspeceVertebré() { //comportement commun}
} ;

class Serpent : IEspeceVertebré
{
   EspeceVertebre _EspeceVertebré = new EspeceVertebré()

   void UneMethodeEspeceVertebré()
   {
      _EspeceVertebré.UneMethodeEspeceVertebré();
      //spécifique au serpent
   }
}

class Oiseau : IEspeceVertebré, IEspeceAvecPatte 
{
   EspeceVertebre _EspeceVertebré = new EspeceVertebré();

   void UneMethodeEspeceVertebré()
   {
      _EspeceVertebré.UneMethodeEspeceVertebré();
      //spécifique à un oiseau
   }
void UneMethodeEspeceAvecPatte(){}
}

[bruno_pages]

l'héritage multiple est ni plus ni moins utile que l'héritage simple

remettre en question l'héritage multiple sans remettre en question l'héritage simple n'est qu'une malhonnête tentative d'explication de l'absence d'héritage multiple dans certains langages

a partir du moment ou on remplace un héritage par une association les opérations qui auraient du être naturellement héritées ne le sont plus et il faut passer les définir pour en interne appliquer la chose sur l'association, avec tout cela compte de risque lorsque la classe associée bouge ... bref c'est de la bidouille

c'est votre père ou votre mère que vous ne considérez pas comme étant un parent ?

[hegros]

c'est votre père ou votre mère que vous ne considérez pas comme étant un parent ?

Je ne suis pas d'accord, il n'y a pas qu'une seule façon de modéliser un problème

D'ailleurs dans les 2 diagrammes ci-joint il n'est pas question d'héritage multiple pour ce problème de parent, mère, père...

[Bluedeep]

.. bref c'est de la bidouille

Il est de notoriété publique que l'usage de l'héritage multiple ce n'est jamais de la bidouille......

[bruno_pages]

ni plus ni moins que l'héritage, ou tout autre concept dans n'importe quel langage de programmation puisque malheureusement une partie significative du code développé dans le monde est plus de la bidouille qu'autre chose

il faut donc interdire la programmation ...

cette discussion vire au troll, comme toute discussion ou on met en avant les manques flagrants dans java/c# (ce qui ne veut pas dire que rien ne manque à C++ )

[hegros]

Mouais c'est bof par rapport aux arguments présentés et que j'ai pu lire, sauf peut-être pour l'intellisense

C'est intéressant dans 1% des codes écrit en C++, d'ailleurs à ma connaissance la bibliothèque standard ne l'utilise pas non plus, ce qui prouve bien que ce n'est pas un manque puisque dans 99% on peut s'en passer. Ce qui ne veut pas dire que le C# ou le Java soit parfait

[oodini]

cette discussion vire au troll

Vertébré bipède, il me semble.

[Bluedeep]

Vertébré bipède, il me semble.

Bipède oui mais pas certain qu'ils soient vertébrés. Selon certains auteurs, les trolls auraient une nature minérale; donc leur peau est assimilable à un exosquelette; pas certains du tout qu'ils soient vertébrés

[oodini]

Une nature minérale ?

Damned !! Cela remet complètement cause le diagramme de classes établi par le Grand Architecte !