Le probl\u00e8me ici, c’est que la classe Integer h\u00e9rite d\u00e9j\u00e0 de la classe Number, qui permet la gestion des op\u00e9rations sur les nombres. Puisque Java ne g\u00e8re pas l’h\u00e9ritage multiple, la classe Comparable doit \u00eatre une interface. Par contre, math\u00e9matiquement, les classes enfants de Comparable devraient seulement impl\u00e9ment\u00e9 une seule m\u00e9thode (< ou >). Si nous supposons que la m\u00e9thode plus petit (<) est impl\u00e9ment\u00e9e (par l’enfant de Comparable), voici du pseudo-code qui montre comment impl\u00e9menter les diff\u00e9rentes autres m\u00e9thodes de Comparable. Noter que l’objet en cours est repr\u00e9sent\u00e9 par cet_objet (en d’autres mots, si on compare \u00e0 Java, \u00ab\u00a0this = cet_objet\u00a0\u00bb):<\/p>\n
\n
fonction >(autre:Comparable) faire\r\n\tRetourne autre < cet_objet\r\nfin\r\n\r\nfonction !=(autre:Comparable) faire\r\n\tRetourne (cet_objet < autre) ou (cet_objet > autre)\r\nfin\r\n\r\nfonction ==(autre:Comparable) faire\r\n\tRetourne non(cet_objet != autre)\r\nfin\r\n\r\nfonction >=(autre:Comparable) faire\r\n\tRetourne (cet_objet > autre) ou (cet_objet == autre)\r\nfin\r\n\r\nfonction <=(autre:Comparable) faire\r\n\tRetourne (cet_objet < autre) ou (cet_objet == autre)\r\nfin<\/pre>\n<\/div>\nOn voit donc que la seule m\u00e9thode de Comparable qui doit r\u00e9ellement \u00eatre impl\u00e9ment\u00e9 dans les Enfants de Comparable, c’est < (ou >). Le probl\u00e8me, c’est qu’en utilisant une interface au lieu d’une classe, on doit impl\u00e9menter le code des autres m\u00e9thodes (>, !=, ==, >= et <=) dans toutes les classes enfants de Comparable. En d’autres mots, le code ci-dessus doit \u00eatre copi\u00e9-coll\u00e9 int\u00e9gralement dans chaque classe qui impl\u00e9mente comparable; ce qui augmente consid\u00e9rablement la duplication de code impos\u00e9 par la librairie Java.<\/p>\n
Pour comparer, voici ce qui est fait par la librairie Eiffel en utilisant l’h\u00e9ritage multiple:<\/p>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_comparable_eiffel.png\")
<\/p>\n
On peut donc voir que seulement la m\u00e9thode plus petit (<) est impl\u00e9ment\u00e9e dans les Enfants de Comparable. Toutes les autres m\u00e9thodes sont impl\u00e9ment\u00e9es directement dans la classe Comparable. On diminue donc au maximum la duplication de code impos\u00e9e par la librairie Eiffel.<\/p>\n
Maximiser la r\u00e9utilisabilit\u00e9 des classes.<\/h3>\n
Afin d’avoir tous les avantages de l’h\u00e9ritage, il faut utiliser des classes. Par contre, il arrive que l’h\u00e9ritage simple emp\u00eache l’utilisation de classes qui pourrait \u00eatre utile. Par exemple, voici un diagramme repr\u00e9sentant une Vue repr\u00e9sentant une fen\u00eatre pouvant \u00eatre observ\u00e9e:<\/p>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_observable.png\")
<\/p>\n
Le probl\u00e8me avec ce diagramme, c’est qu’elle n\u00e9cessite l’h\u00e9ritage multiple pour fonctionner. Afin de construire la m\u00e9canique d’observable sans h\u00e9ritage simple, nous allons devoir nous passer de la classe Observable et de placer le code de gestion des Observeurs directement dans la classe Vue. Comme ceci:<\/p>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_simple_observable.png\")
<\/p>\n
Le r\u00e9sultat est que si le responsable de la librairie d’Observable\/Observeur fait des am\u00e9liorations \u00e0 sa classe Observable, la classe Vue ne b\u00e9n\u00e9ficiera pas de ces am\u00e9liorations. De plus, si nous avons plusieurs classes Observable, nous ajoutons de la duplication de code (ce qui rejoint le point plus haut).<\/p>\n
Les mauvais c\u00f4t\u00e9s de l’h\u00e9ritage multiple<\/h2>\n
Il va de soi que, s’il n’y avait que des avantages \u00e0 l’h\u00e9ritage multiple, tous les langages l’auraient impl\u00e9ment\u00e9. Il est donc important de comprendre les probl\u00e9matiques que l’h\u00e9ritage multiple g\u00e9n\u00e8re. Je vais pr\u00e9senter les 2 aspects probl\u00e9matiques majeurs de l’h\u00e9ritage multiple et je vais indiquer comment les langages impl\u00e9mentant l’h\u00e9ritage multiple ont contourn\u00e9 le probl\u00e8me.<\/p>\n
Les conflits<\/h3>\n
On dit qu’il y a conflit lorsque, \u00e0 cause de l’h\u00e9ritage multiple, la classe enfant se retrouve avec plusieurs m\u00e9thodes diff\u00e9rentes, avec la m\u00eame signature. Par exemple:<\/p>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_conflit.png\")
<\/p>\n
Donc, prenons le code suivant:<\/p>\n
\n
Classe_C<\/span> monObjetC<\/span> =<\/span> ...;<\/span>\r\nmonObjetC<\/span>.<\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\nLa question est donc: \u00ab\u00a0Est-ce que c’est la m\u00e9thode f() de Classe_A ou bien la m\u00e9thode f() de Classe_B qui sera lanc\u00e9e? Il est impossible de r\u00e9pondre \u00e0 cette question sans r\u00e9gler le conflit. Les diff\u00e9rents langages ont diff\u00e9rente mani\u00e8re re g\u00e9rer les conflits. Voici des m\u00e9thodes utilis\u00e9es dans diff\u00e9rents langages pour r\u00e9gler les conflits.<\/p>\n
En Python<\/h4>\n
En Python, le langage ne g\u00e8re aucun conflit. La m\u00e9thode f() qui sera lanc\u00e9e est la premi\u00e8re m\u00e9thode trouv\u00e9e par Python. Par exemple, si je prends cette classe:<\/p>\n
\n
class<\/span> Classe_C<\/span>(<\/span>Classe_A<\/span>,<\/span> Classe_B<\/span>):<\/span>\r\n<\/pre>\n<\/div>\nLa m\u00e9thode f() qui sera lanc\u00e9e est la m\u00e9thode f() de la Classe_A. Inversement, si je prends cette classe:<\/p>\n
\n
class<\/span> Classe_C<\/span>(<\/span>Classe_B<\/span>,<\/span> Classe_A<\/span>):<\/span>\r\n<\/pre>\n<\/div>\nLa m\u00e9thode f() qui sera lanc\u00e9e est la m\u00e9thode f() de la Classe_B.<\/p>\n
Le gros probl\u00e8me avec cette m\u00e9canique, c’est que malgr\u00e9 l’absence de conflit, le fait de changer l’ordre d’h\u00e9ritage change la classe enfant, ce qui n’est pas acceptable au niveau orient\u00e9 objet. En d’autres mots, une classe qui h\u00e9rite de la Classe_A et de la Classe_B devrait \u00eatre la m\u00eame classe que si elle h\u00e9ritait de la Classe_B et de la Classe_A; ce qui n’est pas le cas ici.<\/p>\n
En C++<\/h4>\n
Le langage C++ permet de g\u00e9rer les conflits de la mani\u00e8re suivante. Lorsque le client de la classe fait l’appel de la fonction f(), il doit obligatoirement sp\u00e9cifier il s’agit du f() de quelle classe. Par exemple, le code suivant \u00e9chouera:<\/p>\n
\n
Classe_C<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\nobjet_c<\/span>-><\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\nSi nous voulons le faire fonctionner, nous devrons utiliser le code suivant pour utiliser le f() de la Classe_A:<\/p>\n
\n
Classe_C<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\nobjet_c<\/span>-><\/span>Classe_A<\/span>::<\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\net le code suivant pour utiliser le f() de la Classe_B:<\/p>\n
\n
Classe_C<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\nobjet_c<\/span>-><\/span>Classe_B<\/span>::<\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\nUne autre m\u00e9thode que le client peut utiliser est d’utiliser un type diff\u00e9rent pour la variable. Par exemple, ce code lancera le f() de la Classe_A:<\/p>\n
\n
Classe_A<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\nobjet_c<\/span>-><\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\net le code suivant lancera le f() de la Classe_B:<\/p>\n
\n
Classe_B<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\nobjet_c<\/span>-><\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\nOn peut \u00e9galement \u00ab\u00a0typer\u00a0\u00bb l’objet pour s’assurer d’utiliser la fonction recherch\u00e9e. Par exemple, le code suivant lancera le f() de la Classe_A:<\/p>\n
\n
Classe_C<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\n((<\/span>Classe_A<\/span>*<\/span>)<\/span>objet_c<\/span>)<\/span>-><\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\net le code suivant lancera le f() de la Classe_B:<\/p>\n
\n
Classe_C<\/span>*<\/span> objet_c<\/span> =<\/span> new<\/span> Classe_C<\/span>();<\/span>\r\n((<\/span>Classe_B<\/span>*<\/span>)<\/span>objet_c<\/span>)<\/span>-><\/span>f<\/span>();<\/span>\r\n<\/pre>\n<\/div>\nToutes ces m\u00e9thodes, quoique fonctionnelles, ont \u00e9t\u00e9 critiqu\u00e9es par les experts du domaine des langages de programmation puisqu’elles laissent le soin au client de la classe de choisir dans quelle classe parent trouver la m\u00e9thode ou l’attribut \u00e0 utiliser. De ce fait, les m\u00e9canismes de gestion de conflit contreviennent au principe d’encapsulation, un des piliers du concept orient\u00e9 objet.<\/p>\n
En Eiffel<\/h4>\n
Afin de respecter au maximum tous les principes objet, Eiffel s’est dot\u00e9 d’une section \u00e0 part dans le code d’une classe afin de pr\u00e9ciser tout ce qui a \u00e0 pr\u00e9ciser au niveau de l’h\u00e9ritage. Ainsi, des m\u00e9canismes plus complexes ont pu \u00eatre d\u00e9velopp\u00e9s afin de g\u00e9rer \u00e9l\u00e9gamment les conflits. Le m\u00e9canisme le plus courant afin de r\u00e9gler un conflit consiste \u00e0 renommer un ou plusieurs attributs ou m\u00e9thodes afin de faire dispara\u00eetre l\u2019ambigu\u00eft\u00e9. Par exemple, ce code de la CLASSE_C donnera une erreur:<\/p>\n
\n
class<\/span>\r\n\tCLASSE_C<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_A<\/span>\r\n\tCLASSE_B<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\nL’erreur nous indique que la CLASSE_C contient deux m\u00e9thodes diff\u00e9rentes avec le m\u00eame nom. Nous pouvons donc renommer une des deux m\u00e9thodes en utilisant la clause \u00ab\u00a0rename\u00a0\u00bb:<\/p>\n
\n
class<\/span>\r\n\tCLASSE_C<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_A<\/span>\r\n\t\trename<\/span>\r\n\t\t\tf<\/span> as<\/span> f_de_a<\/span>\r\n\t\tend<\/span>\r\n\tCLASSE_B<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\nCe code compile sans probl\u00e8me puisqu’il n’y a plus de conflit. Il aurait \u00e9galement \u00e9t\u00e9 possible de renommer les deux m\u00e9thodes f. Par exemple:<\/p>\n
\n
class<\/span>\r\n\tCLASSE_C<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_A<\/span>\r\n\t\trename<\/span>\r\n\t\t\tf<\/span> as<\/span> f_de_a<\/span>\r\n\t\tend<\/span>\r\n\tCLASSE_B<\/span>\r\n\t\trename<\/span>\r\n\t\t\tf<\/span> as<\/span> f_de_b<\/span>\r\n\t\tend<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\nDans le cas ou nous ne voudrions seulement une des deux m\u00e9thodes des classes parents, nous pourrions tous simplement demander au compilateur d’oublier la m\u00e9thode qui ne nous int\u00e9resse pas avec la clause \u00ab\u00a0undefine\u00a0\u00bb. Par exemple:<\/p>\n
\n
class<\/span>\r\n\tCLASSE_C<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_A<\/span>\r\n\tCLASSE_B<\/span>\r\n\t\tundefine<\/span>\r\n\t\t\tf<\/span>\r\n\t\tend<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\nUne derni\u00e8re possibilit\u00e9 serait de red\u00e9finir la m\u00e9thode f(). Cette m\u00e9thode permet \u00e9galement de cr\u00e9er une seule m\u00e9thode f() dans CLASSE_C qui lancerait autant la m\u00e9thode f() de CLASSE_A et la m\u00e9thode f() de CLASSE_B avec le mot cl\u00e9 \u00ab\u00a0precursor\u00a0\u00bb. Par exemple:<\/p>\n
\n
<\/span>class<\/span>\r\n\tCLASSE_C<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_A<\/span>\r\n\t\tredefine<\/span>\r\n\t\t\tf<\/span>\r\n\t\tend<\/span>\r\n\tCLASSE_B<\/span>\r\n\t\tredefine<\/span>\r\n\t\t\tf<\/span>\r\n\t\tend<\/span>\r\n\r\nfeature<\/span>\r\n\r\n\tf<\/span>\r\n\t\tdo<\/span>\r\n\t\t\tPrecursor<\/span> {<\/span>CLASSE_A<\/span>}<\/span>\r\n\t\t\tPrecursor<\/span> {<\/span>CLASSE_B<\/span>}<\/span>\r\n\t\tend<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\nLe probl\u00e8me du diamant<\/h2>\n
Le probl\u00e8me du diamant est le probl\u00e8me le plus important dans le principe d’h\u00e9ritage multiple. Il n’existe pas de m\u00e9canisme vraiment facile et \u00e9l\u00e9gant \u00e0 ce jour pour g\u00e9rer ce probl\u00e8me. Il est par contre important de sp\u00e9cifier qu’heureusement, il est tr\u00e8s rare que ce probl\u00e8me arrive r\u00e9ellement dans un programme r\u00e9el.<\/p>\n
Ce probl\u00e8me arrive lorsqu’une classe parent sp\u00e9cifie une m\u00e9thode, que plusieurs de ses classes enfants red\u00e9finissent cette m\u00e9thode et que finalement, une classe h\u00e9rite de ces classes enfants. Voici le diagramme de classe repr\u00e9sentant cette situation:<\/p>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_diamant.png\")
<\/p>\n
Cette m\u00e9canique semble similaire au conflit pr\u00e9ciser plus haut, mais la subtilit\u00e9 repose dans un cas d’utilisation sp\u00e9cifique. Pour la repr\u00e9senter, voici un exemple Eiffel qui utilise la m\u00e9canique de \u00ab\u00a0rename\u00a0\u00bb indiqu\u00e9e plus haut. Cela devrait vous montrer d’o\u00f9 vient la probl\u00e9matique du probl\u00e8me du diagramme.<\/p>\n
Premi\u00e8rement, voici la CLASSE_PARENT:<\/p>\n
\n
deferred<\/span> class<\/span>\r\n\tCLASSE_PARENT<\/span>\r\n\r\nfeature<\/span>\r\n\r\n\tf<\/span>\r\n\t\tdeferred<\/span>\r\n\t\tend<\/span>\r\nend<\/span>\r\n<\/pre>\n<\/div>\nLes deux classes enfants seront les suivantes:<\/p>\n
\n
class<\/span>\r\n\tCLASSE_A<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_PARENT<\/span>\r\n\r\nfeature<\/span>\r\n\r\n\tf<\/span>\r\n\t\tdo<\/span>\r\n\t\t\tprint<\/span>(<\/span>\"A%N\"<\/span>)<\/span>\r\n\t\tend<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\n\n
class<\/span>\r\n\tCLASSE_B<\/span>\r\n\r\ninherit<\/span>\r\n\tCLASSE_PARENT<\/span>\r\n\r\nfeature<\/span>\r\n\r\n\tf<\/span>\r\n\t\tdo<\/span>\r\n\t\t\tprint<\/span>(<\/span>\"B%N\"<\/span>)<\/span>\r\n\t\tend<\/span>\r\n\r\nend<\/span>\r\n<\/pre>\n<\/div>\n
![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_exemple.png\")
<\/p>\n![\"\"](\"https:\/\/www.louismarchand.me\/wp-content\/uploads\/2021\/10\/heritage_multiple_comparable.png\")
<\/p>\n