Pen^2 (./30) :
Concernant le java il ne s'agit pas exactement de compenser, mais de proposer une vision plus propre que l'héritage multiple.

Ça dépend du point de vue, hein.

Et la preuve que l'héritage multiple manque, c'est que le Java 8 a rajouté les "méthodes par défaut" (implémentations par défaut des méthodes) dans les interfaces, ce qui simule l'héritage multiple (mais est quand-même plus limité parce qu'on ne peut pas faire de l'héritage multiple de classes normales, il faut les transformer en interfaces avec méthodes par défaut). En particulier, le fameux "problème du diamant" ("diamond problem", plus correctement, mais plus rarement, traduit "problème du losange"), la principale excuse pour ne pas permettre l'héritage multiple, existe aussi avec les "méthodes par défaut".

C'est peut-être une habitude biaisée, mais l'héritage multiple ne me manque pas du tout, et d'ailleurs même l'héritage tout court ne me sert pas tant que ça.

J'ai déjà plusieurs fois utilisé l'héritage multiple en C++ et j'ai aussi déjà rencontré des cas en Java où ça m'a manqué.

Cela dit, j'ai aussi déjà eu le problème en C++ d'avoir un graphe de dérivation en losange ("diamant"), et la solution pour permettre cela proprement ("héritage virtuel") aurait nui à la performance bien plus que quelques champs membre non utilisés, donc dans ce cas, je suis repassé à un héritage simple et des champs optionnels. Ce n'était pas le "problème du diamant" classique (le conflit d'implémentations) le problème, mais la nécessité d'avoir une seule copie des champs de la classe de base.