Bonjour,
 
 j'ai pris la section Java car je vais appliquer ma question à l'environnement de développement Java
 
Je me suis toujours demandé à quoi pouvait bien servir une Interface (par rapport à une classe abstraite je m'entend)
 
 Lorsque l'on défini une interface, on y met les Methodes sans y mettre l'implementation. Par exemple, si j'ai une methode getFile et getDirectory, je ne met QUE les squelettes de methodes et non pas leur implementation.
 
A quoi cela sert il ? En faisant une classe Abstraite (Implementation plus interface) on s'y retrouve aisement.
 
A chaque fois que l'on implemente une interface nous sommes obligés de définir les implementations de chaque méthode, et je n'arrive pas à comprendre bien l'utilité.
 
Si on s'en referre à Java, dans une interface, les methode sont publiques (on peut l'indiquer mais c'est implicite) et l'on peut meme (je ne sais pas si c'est Object Compliant, un pro de l'Objet pourrait peut etre confirmer) mettre des "Attributs" en Static Final (implicite aussi, c'est pour certaines constantes par exemple)
 
Soit la classe A qui implemente l'interface I, A doit redefinir les methodes de I (implementation)
 
Maintenant je cherche l'utilité, si par exemple une classe B voudrait utiliser l'interface I via A
 
Pour des Langages ne supportant pas l'heritage multiple, on peut concevoir que l'interface peut etre utile, car nous ne sommes pas limité au nombre d'implementation d'interfaces (donc en C++, les interfaces ne seraient pas utiles)
 
Mise a part l'interface callback je ne vois pas l'utilité.
 
Je sais que l'on peut faire Interface uneinterface = new ClasseQuiImplementeInterface() et dans ce cas là nous pouvons, via les methodes implementées utiliser une interface "complete"
 
Mais a part ça, j'ai du mal à comprendre.
 
Quelqu'un pourrait expliquer clairement et calmement ?

 
   
 
Dans certains langages, on émule le mécanisme d'interface avec l'héritage multiple.

Je sais pas si j'vais être hyper convaincant, m'enfin on va dire que c'est pas le but
On dit généralement que l'interface est un contrat. J'aime pas trop cette formulation mais c'est vrai que c'est ce qui s'en rapproche le plus. En fait, une classe qui implémentera une interface s'engagera à fournir les méthodes énoncées dans l'interface. C'est vraiment juste pour la conception, je ne pense pas que ça ait un impact quelconque sur le bytecode qui est généré au final.
Par exemple, le dev qui lit la doc ou le code d'une classe qui implémente l'interface Comparable saura que la classe en question pourra être appelée sur une méthode compareTo() et à partir de là utiliser des objets qui permettent de comparer des objets ou autres utilisations nécessitants le passage d'objets implémentant Comparable.

+1 avec ce qu'à dit Taiche. Le terme de "contrat" est vraiment approprié.
 
En ce qui concerne les attribut static final des interfaces, c'est une abération que ce truc existe. un conseil : oublie qu'on peut faire ca.
 
les classes abstraites sont un peu une facilité. La vrai notion c'est l'interface. Une classes abstraite c'est juste une classe qui ne remplit qu'une partit du contrat et qui la tache à une autre classe de remplir le reste.
 
sinon, pour philosopher un peu : Quand tu fais de la conception et que tu commences à réfléchir à l'architecture objet de ton appli, tu réfléchis à quoi va servir cet objet, qu'est ce qu'il sera capable de faire. en fait tu penses en terme d'interface. Les objets c'est juste la brique qui va entrer dans le moule que tu as imaginé. Mais l'important, c'est pas la brique, mais le moule !  
 
 
bref, les interface c'est bien !

tiens j'aurais dit l'inverse

C'est le grand conflit de Java vs C++.
Perso, je pense plus comme toi parce que j'estime que qu'un contrat ne dois pas se limiter uniquement aux méthodes mais devrait également pouvoir s'appliquer sur des propriétés pour garder une plus grande homogénéité interne des structures.

d'autres langages font eux aussi le pari de l'héritage multiple, ce n'est pas une invention du C++. Les interfaces c'est bien, mis dans certains cas, ça suffit pas.

Merci pour ces infos, j'y vois deja plus clair

   
 
au moins harko change de pseudo pour troller ...

y a pas de troll. dans la vie de tous les jours, y a plein de problème qui sont mettent en oeuvre naturellement l'héritage multiple

et y a plein de façon de s'en sortir sans multi-heritage.  
 
C'est peut-être plus laborieux, mais on peut toujours s'en sortir.
 
=> c'était un troll =>

 
et encore bcp plus de bugs incompréhensibles du /à la mauvaise utilisation de l'héritage multiple
 

ouais !!!!  

vous énervez pas, sam a posé une question sur la cat Java mais son sujet est plus large. c'est dingue, vous voulez jamais discuter

  je suis calme moi.
 
dark et moi on a argumenté, j'attend le contre-argument ...

 
+1 j'ai juste mis un   pour souligner mon indigniation stou

les kaola et et les accusations de troll, c'est ce que t'appelle etre calme.
 
pour l'argument d'erreur avec l'heritage multiple, je n'est pas assez d'expérience, mais j'avoue ne pas voir ou est vraiment le danger. après comme tu dis, faire avec un langage sans héritage multiple, c'est laborieux, et comme on le sait tous, plus y a de code plus y a d'erreurs. et ça me pose une question: comment ne pas passer son temps à tout réécrire / faire du travail sain: il me semble que la composition a ses limites. alors oui c'est laborieux, mais ecrire en asm ça l'est aussi. la relation traditionnelle en losange devient quand même galère  
 
      A
 
B(A)    C(A)
 
 
   D(B, C)
 
 
comment on fait en java ? il faut que D est l"interface" de A, B, C et soit a part entière un A, un B, et un C. un exemple s'il vous plait  
 
 
edit: j'envisage bien de faire une interface par objet, mais quelle galère !

on fait pas

la bonne excuse ...

T'as un exemple concret ? Passke j'ai du mal à comprendre c'que tu veux faire. L'héritage en diamant, c'est un concept horrible : imagine que dans B tu surcharges une méthode de A et pareil dans C mais d'une façon différente. Dans D, quand tu fais super.maMethode(), c'est laquelle qui sera choisie ?
'fin chépa, moi c'est conceptuellement que ce genre de truc me pose un problème, c'est même pas lié au langage

 
Aucune, l'appel étant ambigüe, le C++ te demandera d'expliciter laquelle sera appelée.

Bin ui mais le langage mis à part, je comprends pas conceptuellement l'intérêt du bordel

et d'autres langages aussi.
 
des exemples ? ben un truc tout bête, y a quelque jours, je bricolais, et j'ai fabriqué mes propres exceptions. chaque classe d'exception transporte un message textuel (et dans mon cas une référence à un objet)
 
std::exception est bien évidemment ma classe mère
 
ExceptionA correspond à un certain type d'erreur.
ExceptionB correspond à un deuxième type d'erreur
 
 
je codais et puis je suis tombé sur un endroit ou j'avais du code  qui devait lancer une exception. mais cette exception relève autant du problème A que tu problème B. donc il me fallait une classe ExceptionAB héritant de ses deux classes d'exceptions. et c'est très bien
 
à certains endroit, j'attrape des A, à d'autres de B, en encore à un autre des AB

ben l'héritage multiple me parait être une relation naturelle. j'ai moi même 2 géniteurs.

J'vois pas très bien le rapport avec l'héritage (au sens Prog, hein ). Ou alors c'était une blague

ben moi et mes clones, on partage les caractéristiques de mes parents (ie leur code).

Tes parents savent faire des trucs que tu sais pas faire. T'es pas une spécialisation de tes deux parents. Comme t'es de la même famille, par contre, on peut parler d'une relation d'agrégation à l'intérieur de la famille ; j'te mettrais dans le même package, lors de l'implémentation
 
Ah pis sinon, une autre question pratique sur l'héritage multiple : t'as un membre public de ta classe A, t'utilises quelle instance dans ta classe D ? Celle de B ou celle de C ? Dans la mémoire, t'hérites des deux ? Si oui, ça pose pas un problème de redondance ? Sinon, sur quoi est basée la sélection ?
'fin ch'ais pas, dans tout ce qu'on m'a appris on m'a toujours dit que l'héritage multiple apportait plus de problème qu'il n'en résolvait Du coup, j'en ai pratiquement jamais fait mais en même temps j'en ai pas eu besoin, tout ce que j'ai fait je me suis basé sur de l'héritage simple. Donc j'me demande surtout si y a un réel besoin pour cette fonctionnalité qui ne saurait pas être résolu par de l'héritage simple avec interfaces.

la redondance est évitée par un mécanisme virtuel (virtual en C++, à spécifier explicitement) qui assure l'unicité de chaque base

je suis d'accord avec Taz : l'héritage multiple a vraiment un sens. Il y a des cas où c'est utile et d'autres cas, où conceptuellemet il est normal de dire qu'une classe peut "prendre 2 casquettes"
 
Par contre, l'implémentation et l'utilisation de ce genre de cas est plus difficile et c'est généralement la source de pas mal d'incompréhension et de bug vicelard.
 
Bref, dans un but de simplification, en Java il a été choisit de ne pas faire d'héritage multiple. Par contre, ils ont tout miser sur le concept d'interface qui remplit 95% des besoins. Pour les 5% restant (quand on a VRAIMENT besoin d'héritage multiple), on peut émuler cet héritage multiple par une bête agrégation.
 
exemple :  
 

 
 
remarque : dans ABImpl, je peux très bien hériter de A et agréger B pour éviter d'avoir à implémenter les méthodes de A.
 
donc, ok, c'est plus chiant à écrire (ca peut se faire de façon automatique), mais on a exactement le comportement de l'héritage multiple.

comme je pensais. tu as des outils précis quand tu parles de « écriture automatique »
avoue que c'est chiant quand même, surtout pour des classes qui ne font rien, et tu l'élude pas le problème de la relation en losange: la composition entraine la redondance. mais ... j'ai l'impression que Sun a voulu se simplifier la tache plutot qu'autre chose. par ce que franchement il existe beaucoup de langages qui supportent l'héritage multiples, et quant à leur programmeurs et bien, certains ignore complètement celà, d'autre y trouve leur bonheur, et certains utilisent des classe abstraites comme interface. donc en fait je me pose la question: en terme d'utilisation, n'y a t il pas plus de raison de fournir l'héritage multiple plutôt que non? mais là je dévie du sujet

Non, je n'ai jamais vu d'outil proposant ce genre de truc.
1) je suis capable de le faire en 1 heure
2) si aucun IDE ne le propose alors que c'est très simple à faire, y a un raison : on ne s'en sert quasiment jamais !!!!
 

   
explique moi le problème du losange parce que je vois pas. Autant dans le cas des langage à héritage multiple ca pose problème, mais là avec des interface, pas de soucis !
 

  bha tiens. Parce que tu crois que c'est n'importe quel bozo qui a créé le Java ??? Ne pas avoir intégré l'héritage multiple est un choix, pas une lacune. Pour qui te prend tu pour émettre ce genre de jugement.  
"Hahaha, Sun même pas capable de faire de l'héritage multiple"
   
 
 

c'est bien ca le problème !!!!
certains développeurs vont utiliser des librairies utilisant des notions qu'ils ne connaissent pas. Et en cas de problème, ils vont en chiser pour comprender pourquoi ca ne marche pas puisqu'ils ne seront même pas capable de comprendre pourquoi ca devrait marcher.
 
Le java c'est simple : tu arrives rapidement à saisir toutes les fonctionnalités du langage.
 
En tout cas, personnelement, j'ai très rarement été confronté au problème de l'héritage multiple et j'ai systématiquement trouvé le moyen de m'en sortir très facilement.  
Donc, de part mon exepérience, je trouve que Sun a eu raison de ne pas complexifié son langage, juste pour gérer quelques cas rares, qui sont de toutes façon saulvable au prix d'un petit effort.

bon, je bataille pas...
 
pour en revenir au losange, si A et B hérite toujours de quelque chose (dans certains langages, comme Java, c'est une classe mère de tout, mais on prends le cas d'une classe M) et bien chaque instance d'AB posséde en double les membres M. et ça c'est problématique. apparaitre comme etre un A et un B, c'est bien, mais ça ne suffit pas.
 
il me semble pas que l'héritage multiple soir quelque chose de difficile à comprendre, du moins, c'est peut etre aussi(plus) rapide que de comprendre la présence et de classes, et de classes abstraites et d'interfaces (la réponse étant : par ce que y a pas d'héritage multiple ; )

Le fait d'avoir une arborescence est bien plus simple que d'avoir une architecture en graphe ...
 
ton problème avec les attributs membre c'est typiquement le genre problème à la con avec l'héritage multiple.
 
Alors que quand tu penses en terme d'interface, cad de contrat que doivent remplir les objets, ce problème n'existe plus.
 
C'est dans ce sens là que le dit que Java a fait le choix de la simplicité.
 
Da plus, l'existance des interface & classes abstraites n'a rien à voir avec l'héritage multiple. C'est un concept très puissant. Il permet de régler le problème d'héritage multiple mais c'est pas ca le but

T'as commencé, tu finis

oui mais une interface, c'est du vent, rien de concret
 
 

ben non, au contraire, c'est parfaitement gérer
 
la notion d'héritage multiple est manipulée par les connaisseurs, l'argument de la simplicité me satisfait pas vraiment, surtout que ça n'est pas très sorcier il me semble.
 
 
en fait mon vrai problème avec Java, c'est que je ne comprends pas sa conception    

 
ils ont fait tout un tas de choix à la conception, dans l'idée de prendre tout ce qu'il y avait de bien dans les langages impératifs OO existants, en écartant l'inutile et le compliqué.
 
Evidement, les choix qu'ils ont faits sont discutables.

 
Les interfaces c'est la base de tout !!! C'est la définition des messages échangés entre les objets, ce qui est la base de la programmation objet.
 
Quand tu as les interfaces tu as 70% du prog. Le reste c'est plus que de la bête implémentation et du cablage.  
 
Je suis étonné que tu t'en rende pas compte de l'intérêt de la chose  
C'est de l'abstraction pure. C'est quand même une notion répandue en programation : t'as la même chose en Ada ...

 
le fond algorithmique, ça a aussi son importance

bha, les algos qu'on manipule dans la prog de tous les jours sont quand même vachement basiques. La conception de l'architecture du prog est bien plus importante, tu penses pas ?