j'ai un peu de mal à comprendre le concept implement :
 
c'est une importation des squelette methodes uniquement sans paramètre ou quoi ?
 
je suis un peu dans le flou et malgrès des docu différentes : il prennent tous le même exemple que je pige pas vraiement.
 
si qqun peux passer une petite explication ça sera bien pour ma lenterne.

Conceptuellement il y a les classes et les interfaces. Une interface est une classe dont les methodes ne sont pas implementee, et qui n'a pas d'attribut.
Lorsque tu definit une nouvelle classe elle derive d'une autre classe, et elle peut implementer plusieurs interfaces, c'est a dire en definir les methodes...
 
Une interface sert a specifier une classe ou une famille de classe independement de la maniere de les implementer.
 
exemple tu peut definir une interface d'objet graphique,  
interface GraphElement
{
public Draw(...);
public Move(...);
}
/* Oui c'est une syntaxe simplifiee */
 
Mais nulle part on dit comment GraphElement se dessine, ce sont les classes qui implementent GraphElement qui definissent cela. A l'utilisation, tu n'a que a connaitre GraphElement, et si tu fais un module qui utilise des objets implementant l'interface GraphElement, ce module pourra utiliser des objets definis ailleurs independement de facon toute naturelle.
 
l'interface est une chose reelement importante en conception objet...

Implement est utilisé pour les interfaces. C'est la seule manière de contourner le fait que Java ne fasse pas le multi-héritage vu qu'une sous-classe ne peut dériver que d'un seule classe mais de plusieurs interfaces.
 
Tu définis une interface de la même manière qu'une classe sauf qu'il n'y a aucune implémentation (c'est une classe abstraite en fait,  il n'y a que les prototypes des methodes). Cette implémentation se fera plus tard dans la sous-classe qui implémente l'interface (d'où le 'implement').
 
Pour eviter le copier-coller de code lors d'un multiheritage, on peut fournir des implementations d'interfaces destinées à être agrégées dans les sous-classes qui implémente l'interface (voir les exemples des Swing avec les listeners)

.....eeeeeeeeeeeeeeeeeeeeh....hum!..........hum!
 
ça commence à rentrer mais un exemple claire serai mieux (si vous avez le temps)

on va faire simple :  
 
 
tu as une classe chat, une classe chien, une classe oiseau
et une interface animaux !
bon tu veux dire que un chat,un chien , un oiseau, sont des animaux. Mais tu ne veux pas definir un animal justre en tant qu'animal...donc tu met animal en interface... et les classe chien,chat,oiseau,  vont implémenter animal.
donc chaque fois que tu vas definir une methode dans l'interface animal, tu devras la definir dans la classe chien,chat,oiseau.
 
exemple :  
 
 
 
public class Chien implements animal
{
  public Chien()
  {
    ....
  }
 
  public void crier()
  {
    System.out.println ("ouaf" );
  }
}
 
public class Chat implements animal
{
  public Chat()
  {
    ....
  }
 
  public void crier()
  {
    System.out.println ("miaou" );
  }
}
 
 
public class Oiseau implements animal
{
  public Oiseau()
  {
    ....
  }
 
  public void crier()
  {
    System.out.println ("meuh" );  // ouiiiiiii un oiseau ca fait meuh !!
  }
}
 
donc pour l'instant ton interface animal va juste devoir definir une methode vide crier() !! et pis voila...donc comme ca tu specifiera le fait qu'un animal doit savoir crier pour etre un animal
 
t'as vu l'exmeple de malade un peu !!!!

nomad >en fait, une interface NE SERT PAS A FAIRE LA MEME CHOSE QUE L'HERITAGE MULTIPLE c'est deux notions completement differentes.
 
Dans l'heritage multiple, tu herite d'un comportement et d'attributs de la classe mere (a moins bien sur d'heriter toujours de classes abstraites sans attributs auquel cas ta classe c'est une interface)
 
Les interfaces, il faut les voire comme un contrat passe entre le developpeur de l'objet et le developpeur qui va utiliser l'objet. Implementer une interface c'est donc s'engager a respecter ce contrat. L'interface joue donc seulement un role de canevas pour l'objet qui l'implemente.
Pourqoui sinon on aurait change le mot clef extends pour implements?

Je rajoute juste que c'est une confusion fréquemment faite car le C++ ne dispose pas du lien de réalization entre classe et interface, ce qui fait qu'on l'émule généralement à grand coups d'héritage multiple.

en fait une interface est une class abstraite ou toutes les methodes sont abstraites.
 
ps : tu peux aussi t'en servir pour specifier des constantes. c meme bien util pour ca, pour mettre toutes les constantes d'une appli.

j'ai du mal a comprendre ton propos là...tu peux approfondir ton idée...

 
C'est pas ce que j'ai dit. Encore heureux d'ailleurs car ça serait bien si les interfaces avaient au moins des attributs. J'ai dit que l'interface était ce que Sun avait inventé pour pallier à l'absence d'héritage multiple.
 
Disons que quand on vient du C++, une interface, c'est jamais qu'un cas particulier de classe abstraite sans attributs et la distinction extends/implement est uniquement pour des raisons techniques.
 
En conception objet par exemple, il n'y a pas cette distinction, on parle juste de classe abstraite ou non

 
UML prévoit qu'une classe peut realiser (d'ou le fait que je parlais de realize tout à l'heure, j'ai facilement mon coté UML qui remonte) des interfaces.

Certains utilisent en C++ ce qu'il appellent des interfaces concretes, c'est a dire dont certaines methodes ont une implementation disont par defaut. Quand on les realise on n'est alors pas oblige d'implementer toute l'interface.
 
Pour ma part je trouve que l'heritage multiple (C++) est plus riche que l'implementation d'interface (Java). Mais il pose aussi beaucoup plus de Problemes quand les classes heritees ne sont pas des classes abstraites sans attributs...

je suis pas torp d'accord sur ce point, c sur que c chiant de ne pas pouvoir faire de l'heritage multiple mais bon ca pose moins de problemes de duplication (grace aussi a la liaison dynamique)  de methodes et ca oblige a bien programmer aussi  

under > Ce qui est chiant avec les implementation d'interface c'est que tu sois obligee de definir toutes les methodes de l'interface. C'est la le vrai avantage de l'heritage multiple, mais je reconnais qu'il ne faut pas en abuser... et en particulier il faudrait jamais avoir besion de l'heritage virtuel, mais la on devie, puisque la question etait sur Java...

 
ouais mais avec l'heritage multicple de C++ tu peux te premettre de programmer comme un boeuf....et vas y que je t'etends des classes a gogo...resultats...ben ca chie ;o)...alors la facon de programmer en java t'oblige avoir une certaine rigueur au niveau de ton analyse de probleme... Mais c pas pour ca que java ramera moins  ...c d'ailleurs un peu a cause de l'histoire de la facon dont il gere l'heritage..enfin..ca aussi c une autre histoire ;o)....je crois qu'on va pas reparler des raisons pour lesquelles java est lent...mais bon...avec le temps...
 
en tout cas, je le clame haut et fort java >C++  
 (désolé pour les fans de C++)..Mais on est pas encore au langage 100% objet...

under> le c++ c'est aussi un tres bon language, seulement il n'y a pas les gardes fous de java. La notion d'interface justement eh bien en c++ il faut l'implementer soi-meme et etre suffisament integre pour s'interdire toute derive par rapport au modele objet. C'est rarement le cas. Tu trouveras toujours 10milliards de bonnes excuses pour faire des "saloperies contre-nature" .  
En resume le java est fait pour les hommes, le C++ pour les dieux .
Oula je sens que je m'egare un poil ...

under> le probleme avec le C++, c'est qu'on peut tout faire, y compris les conneries Mais si tu as une bonne conception en amont, tu peux y aller comme un bourrin sur l'héritage virtuel & multiple.
 
Perso j'aime bien le C++ car c'est de l'objet vraiment abouti. C'est un langage où on peut s'affranchir des contraintes matérielles et permet d'avoir une vision réellement algébrique du monde à simuler (je fais beaucoup de programmation sur les simulations / évolution de systèmes).
 
 
J'aime pas Java (même si j'en ai fait pendant 1 an au boulot sous Visual Age) car l'héritage multiple me manque vraiment ou alors ça oblige à faire 1 interface & 1 classe implémenté à chaque fois (comme dans les Swing par exemple quand une classe implemente une interface et agrège l'implémentation de l'interface)
 
En fait, ça me rappelle le débat Heritage/Agrégation et le traité d'Orlando pour ceux qui connaissent

nomad> ouais ca depend des habitudes..moi c le contraire le C++ m'emmerde a cause de son heritage multiple...ce sont deux ecoles...chacun la sienne...mais bon je sui spas d'accord quand tu dis que le C++est de l'objet vraiment abouti c faux !! meme le java n'est pas de l'objet abouti, pour moi de l'objet abouti..ce serait un langage ou TOUT serait objet...et ca ca existe pas encore....Mais pour moi le java est plus proche de l'objet pur, parce que le concept d'interface t'oblige a faire des classes qui soient vraiment bien faites, qui correspondent vraiment à la conception de l'objet de depart defini par l'interface..pour moi c ce qui manque en C++ (bon ca devient polu trop un probleme si le programmeur programme bien dans une vision "objet" mais sinon c vite le fouilli..
Bon tu me diras, en java c possible de faire un fouilli aussi...c sur, mais bon...la c plus un probleme de programmation objet c un probleme d'analyse...
enfin voila mon point de vue    
 
et au fait, c koi ce debat Heritage /Agregation? c sur de l'UML?

under>
 
Le débat Agrégation/Héritage est un débat (à ce que j'en ai lu) qui remonte aux années 80. Le sujet concernait la manière d'implémenter correctemement le concept de généralisation.  
Une école pronait l'héritage et l'autre l'agregation. En fait de compte, ils ont décidé d'utiliser les 2 selon les besoins
 
<Grosse parenthèse hors topic>
 
En fait c'est quasiment 2 philosophies différentes du monde :
 
Exemple simpliste:  
* une Ferrari EST une voiture : Ferrari derive de voiture
* une Ferrari A les fonctionnalités d'une voiture : Ferrari agrège un objet Voiture
 
Comme on le voit, la différence entre agregation et heritage peut être très tenue, surtout qu'au final, tout est codé en agrégation (en mémoire, c'est des structures qui s'emboitent).
 
Je me suis interessé à ça à un moment. Ca m'a permis de comprendre que mon chef de projet etait de l'école agrégation (borné) alors que moi je suis "plutôt heritage non pratiquant" et qu'evidemment on était pas souvent d'accord, mais ceci est une autre histoire...

je démarre en POO donc le C++ connait pas
 
merci pour l'exemple des animaux
merci aussi pour le débat, même si j'ai pas tout compris, ça m'a servi à voir plus clair dans les implements
 
des fois une confrontation de points de vues est plus éclairante qu'une explication, allez savoi pourquoi !