Problème du diamant

Un diagramme d'héritage en diamant.

Le problème du diamant arrive principalement en programmation orientée objet, lorsque le langage permet l'héritage multiple. Si une classe D hérite de deux classes B et C, elles mêmes filles d'une même classe A, se pose un problème de conflit lorsque des fonctions ou des champs des classes B et C portent le même nom. Le nom de ce problème provient de la forme du schéma d'héritage des classes A, B, C et D dans ce cas.

Par exemple, dans le cas d'une interface graphique, une classe Button pourrait hériter de deux classes Rectangle (gérant son apparence) et Clickable (gérant les clics de souris) et ces deux classes hériter d'une classe Object. Si la classe Object définit la fonction equals (gérant la comparaison entre objets), qu'une des deux sous classes Rectangle ou Clickable (ou les deux) étendent cette fonction pour l'adapter à leurs particularités, laquelle des fonctions equals de Rectangle ou de Clickable la classe Button doit elle utiliser? Choisir arbitrairement une seule des deux fonctions ferait perdre l'intérêt de l'héritage; utiliser les deux fonctions pose le problème de l'ordre des appels, de la combinaison des résultats (ou des erreurs), de l'éventuelle redondance de leurs effets, etc.

Approches de résolution

En permettant l'héritage multiple

Les langages de programmation peuvent résoudre ce problème de façons différentes :

• Scala utilise la fonction définie dans la première classe, après avoir aplati l'arbre les traits par une recherche « right-first depth-first » et éliminé les doublons (ne conservant que le dernier des traits surnuméraires). Ainsi, l'ordre de résolution de l'exemple de l'introduction serait [D, C, A, B, A], réduit en [D, C, B, A].

En contournant l'héritage multiple

D'autres langages interdisent plus simplement l'héritage multiple (comme Ada, Ruby, Objective-C, PHP, C#, Delphi/Free Pascal et Java): une classe n'hérite que d'une seule autre, mais peut implémenter une liste d'Interfaces. Ces interfaces ne contiennent que des méthodes abstraites, c'est-à-dire ne contenant aucun code. C'est à la classe C d'implémenter toutes les méthodes de toutes ses interfaces. Les interfaces sont dans ce cas assimilables à des contrats forçant toutes les classes les utilisant d'implémenter les mêmes méthodes.

Notes et références

• (en) Cet article est partiellement ou en totalité issu de l’article de Wikipédia en anglais intitulé « Diamond problem » (voir la liste des auteurs)

Bibliographie

• Eddy Truyen, Wouter Joosen, Bo Nørregaard Jørgensen, Pierre Verbaeten, « A Generalization and Solution to the Common Ancestor Dilemma Problem in Delegation-Based Object Systems », dans Proceedings of the 2004 Dynamic Aspects Workshop, n^o 103–119, 2004 [texte intégral]