Le probleme avec la POO, c'est que C++ et Java ont faconne les esprits des programmeurs qui sont maintenant persuades que l'heritage multiple pose des problemes et casse l'heritage.
Eh bien non! Ca ne casse rien. De toute facon, s'il n'y avait pas d'heritage multiple, on serait quand meme oblige de definir une methode M. Alors devoir faire un choix ne change pas grand-chose. Par ailleurs, il est toujours possible de renommer des methodes heritees...
Quant aux contrats, tu te trompes effectivement: la programmation par contrat d'Eiffel est un mecanisme a base d'assertions logiques. Pour une methode M, tu peux specifier quelles sont les conditions pour l'appeler, et ce qu'elle peut te garantir sur ce qu'elle retourne (c'est le contrat qu'elle te propose). Ca permet ensuite d'eviter de faire un certain nombre de tests qu'on doit d'habitude se taper. Ce qui est interessant, c'est que quand on reecrit une methode dans une classe fille, on herite aussi de ses assertions et on peut les enrichir.
Les interfaces Java n'ont rien a voir avec un contrat. Litteralement, une interface est un type. Et les classes qui implementent une interface sont des classes de ce type. Ca permet de resoudre legerement le manque d'heritage multiple puisque si une classe ne peut avoir qu'une surclasse, elle peut en revanche avoir plusieurs types. L'idee, c'est que les concepteurs de Java considerent que quand on fait de l'heritage multiple, c'est generalement pour avoir plusieurs types, et non pas pour recuperer du code. Le probleme, c'est que quand c'est effectivement pour recuperer du code, on est dans la merde: on est oblige de reecrire des methodes qu'on aurait pu directement heriter (exemple: une applet multithreadee ne peut pas a la fois etendre Applet et Thread, ce qui correspond pourtant bien a la semantique de l'heritage multiple).
Donc s'il n'y a pas d'heritage multiple en Java, c'est surtout parce que ca emmerdait les concepteurs. Ils voulaient un langage tres simple, au risque de perdre de l'expressivite. C'est un choix... qui n'est pas celui d'Eiffel, Sather, Beta, Mjölner, etc, qui fonctionnent tres bien comme ca, merci pour eux.
[^] # Re: Mouais
Posté par Ababacar Octopuce . En réponse à la dépêche Reflexions sur le cliché "on peut faire de l'OO en n'importe quel langage". Évalué à 1.
Eh bien non! Ca ne casse rien. De toute facon, s'il n'y avait pas d'heritage multiple, on serait quand meme oblige de definir une methode M. Alors devoir faire un choix ne change pas grand-chose. Par ailleurs, il est toujours possible de renommer des methodes heritees...
Quant aux contrats, tu te trompes effectivement: la programmation par contrat d'Eiffel est un mecanisme a base d'assertions logiques. Pour une methode M, tu peux specifier quelles sont les conditions pour l'appeler, et ce qu'elle peut te garantir sur ce qu'elle retourne (c'est le contrat qu'elle te propose). Ca permet ensuite d'eviter de faire un certain nombre de tests qu'on doit d'habitude se taper. Ce qui est interessant, c'est que quand on reecrit une methode dans une classe fille, on herite aussi de ses assertions et on peut les enrichir.
Les interfaces Java n'ont rien a voir avec un contrat. Litteralement, une interface est un type. Et les classes qui implementent une interface sont des classes de ce type. Ca permet de resoudre legerement le manque d'heritage multiple puisque si une classe ne peut avoir qu'une surclasse, elle peut en revanche avoir plusieurs types. L'idee, c'est que les concepteurs de Java considerent que quand on fait de l'heritage multiple, c'est generalement pour avoir plusieurs types, et non pas pour recuperer du code. Le probleme, c'est que quand c'est effectivement pour recuperer du code, on est dans la merde: on est oblige de reecrire des methodes qu'on aurait pu directement heriter (exemple: une applet multithreadee ne peut pas a la fois etendre Applet et Thread, ce qui correspond pourtant bien a la semantique de l'heritage multiple).
Donc s'il n'y a pas d'heritage multiple en Java, c'est surtout parce que ca emmerdait les concepteurs. Ils voulaient un langage tres simple, au risque de perdre de l'expressivite. C'est un choix... qui n'est pas celui d'Eiffel, Sather, Beta, Mjölner, etc, qui fonctionnent tres bien comme ca, merci pour eux.