ca sert a quoi a part forcer certaine classe a avoir des methodes communes ? ca sert a ce quil parait ane pas se soucier de la nature de l objet qu on manipule, mais on connait cforcement la nature del objet non ?
 
y aurais pas un petit exemple explicite de son interet ? car sinon je sais un peu comment ca amrche mais sansplus, merci.

Une methode peut prendre en argument une interface, c'est a dire toutes les implementations de cette interface...

En fait, ca sert a palier le GROS manque qu'est l'absence d'héritage multiple en Java. Si tu ne connais pas cette notion, dis le qu'on t'explique un peu plus les bases.

je comprends pas trop la.

bon, j'espère que tu connais les héritages (sinon, apprends ce que c'est, et reviens, g peur que tu comprennes pas sinon ! )
en fait, en prog objet, tu peux avoir des méthode dites abstraites, qui sont uniquement la déclaration de la méthode (sans l'impémentation). en java, on les signal avec le mot clé "abstract" je crois. si une classe contient au moins une méthode abstraite, la classe est elle même abstraite. c à dire qu'on ne peut pas l'instancier. ça peut servir, par exemple, si t'as une classe abstraite "Figure", avec une méthode abstraite "CalcSurface". alors pour qu'une classe héritant de cette classe puisse être instanciée (autrement dit, ne soit pas une classe abstraite), il faut que la classe héritante implémente la  (ou toutes les) méthode abstraite. Dans l'exemple d'avant, si la classe "Cercle" hérite de "Figure", tu devras implémenter, dans "Cercle", la méthode CalcSurface, pour que ta classe "Cercle" soit instanciable...
Une interface, c une classe abstraite dont aucune méthode n'est implémentée : toute ses méthode sont abstraites !
 
ouah ! bon, g écrit ça d'un trait... si tout ne t'apparait pas clairement maintenant, je t'en voudrai pas. Je suis pas toujours hyper doué pour me faire comprendre ! j'aurai au moins essayé; t'en tireras ce que tu peux !

Bon, alors l'héritage multiple, c'est assez simple comme concept, puisse qu'il par du principe qu'un objet complexe est issu d'obje plus primitifs.
 
Ex:  un homme et une femme disposent de caractéristique commune (yeux, coeur, poumons,...) et de caractéristiques différentes (sexe, seins, capacité a faire chier,...). On créer donc des objets oeil, coeur, poumons,... dont chacun des deux objets, homme et femme, héritent. Et on leur ajoute les caractérisitque supplémentaires par la suite. Ainsi, tu n'a créer qu'une fois le coeur et les poumons, ce qui entraine une optimisation en terme de place, de rapidité, de compatibilité et d'évolution.
 
Malheureusement, il est possible de faire des héritages multiples imbriqués, ex: mamifère->ane->baudet  et mamifère-> cheval-> baudet.
Ici, baudet hérite 2x de mamifère, et lors d'appel a une caractéristique du mamifère, il ne sait pas a laquelle il doit faire appel (elle sont identique, mais il ne le sait pas!). Pour éviter ce problème, Java a supprimé l'héritage multiple, mais comme c'était quand même bien pratique, il l'on substitué par les interface, qui ne sontplus que les DECLARATIONS des primitives, sans définir leur manière d'agir, ni les variables qu'elles affectent. Du coup, tu es obligé de retaper le code a la main chaque fois que tu veux l'utiliser.

Plusieurs explications valent mieux qu'une en matière d'héritage.
 
Exemple mega connu :
 
La classe Véhicule est une interface (le volant et les pédales).
 
Les classes Camion et Voiture dérivent toutes les 2 de la classe Vehicule.
 
La classe Conducteur a juste besoin de connaitre la classe Vehicule pour conduire. Si on lui file un pointeur de type Vehicule, le conducteur n'a que faire de savoir s'il s'agit d'une Voiture ou d'un Camion qui a été instancié.
 
C'est le but de l'approche objet : la généralisation
 
Le java ne permet pas le multi heritage. Pour contourner cette lacune, les interfaces sont des classes abstraites totalement vides et il est possible d'en ajouter autant qu'on veut. En fait c'est juste java qui impose cette distinction entre classe vide et classe réelle uniquement pour des raisons techniques.

Il faut plutot voir ca comme un moyen de communication (d'ou ce nom d'interface, qui sert a la communication entre deux milieux).
 
Exemple tres frequent en programmation: tu veux faire un callback. C'est a dire que tu vas dire a une librairie externe que tu veux qu'elle te rappelle(callback) pour certaines taches precises: typiquement la gestion d'evenements a la Windows ou a la Java.
Seul probleme le redacteur de la librairie n'a aucune idee de ce que vont faire tes bouts de programme, sous quelle forme d'objets ils seront implantes etc.. Par contre, il va definir une interface qui va dire: "ok si tu veux que je te rappelle, je veux que tu fournisses les services suivants: oninit, ondraw, onresize, onclose etc.. et que tu me repondes de telle facon pour savoir si l'operation s'est bien deroulee pour toi."
 
Et un objet (le serveur) peut rendre plusieurs services couverts par plusieurs interfaces.
 
Voila principalement comment sont utilisees les interfaces
dans la librairie java.
 
LEGREG

[edtdd]--Message édité par legreg--[/edtdd]

ok je vois unpeut tout ca.
 
l exemple du vehicule me parait pas mal, mais dans le code lui meme je vois pas comment le creer.
 
et ence qui concerne l interrface comme moyen de comm, ca rejoint l idee du conducteur et des vehicules, sauf que la j ail impression qu on pourrait faire ca sur papier, on definit le classes avant la coneption et hop pas besoin dunterface et on crait la classe comme on le desirait, on dit a lindustriel je veux ca ca et ca et qu il me fasse ca et ca, comment je m en fou mais faut qu il le fasse. en fait pour moi l interface on peut largement s enpasser .
 
mais si on passer a ENUMERATION qui est une interface, on peut s en servir dansla classe vector et dans hashtable, et quand on s ensert de enumerationon sait parfaitement que c est un vecteur ou une hashtable et c est un peu pour le conducteur du vehicule, dans ce cas la le conducteur sait parfaitement si c est un camionou une voiture.
 
merci encore et encore merci ci vous continuez a essaye de me faire comprendre .
 
et oui je connais l heritage .
heritage multiple moins, je comprends sans avoir utilise.

Clarkent a écrit a écrit : ok je vois unpeut tout ca.   l exemple du vehicule me parait pas mal, mais dans le code lui meme je vois pas comment le creer.   et ence qui concerne l interrface comme moyen de comm, ca rejoint l idee du conducteur et des vehicules, sauf que la j ail impression qu on pourrait faire ca sur papier, on definit le classes avant la coneption et hop pas besoin dunterface et on crait la classe comme on le desirait, on dit a lindustriel je veux ca ca et ca et qu il me fasse ca et ca, comment je m en fou mais faut qu il le fasse. en fait pour moi l interface on peut largement s enpasser .   mais si on passer a ENUMERATION qui est une interface, on peut s en servir dansla classe vector et dans hashtable, et quand on s ensert de enumerationon sait parfaitement que c est un vecteur ou une hashtable et c est un peu pour le conducteur du vehicule, dans ce cas la le conducteur sait parfaitement si c est un camionou une voiture.   merci encore et encore merci ci vous continuez a essaye de me faire comprendre .   et oui je connais l heritage . heritage multiple moins, je comprends sans avoir utilise.

 
Decidemment, tu n'as pas du suivre le cours
 
En gros, tu peux faire un bout de code qui utilise des enumerations. Mais il n'aura pas besoin de savoir si cette Enumeration provient d'un vecteur ou d'une hashtable... Donc tu vas écrire quelque chose de plus générique et de plsu réutilisable...
 
Sur l'exemple du véhicule, tu vas créer un objet Conducteur... Ce conducteur pourra conduire un véhicule (l'interface), mais lors de la programmation de l'objet, tu ne sauras pas quel est le type du véhicule... Ensuite, toi ou un autre programmeur pourra créer autant de type de véhicules que tu veux (voiture, moto, vélo, navette spatiale): si ils respectent l'interface, ils marcheront très bien avec ton conducteur...

BaNZai a écrit a écrit :     Decidemment, tu n'as pas du suivre le cours   En gros, tu peux faire un bout de code qui utilise des enumerations. Mais il n'aura pas besoin de savoir si cette Enumeration provient d'un vecteur ou d'une hashtable... Donc tu vas écrire quelque chose de plus générique et de plsu réutilisable...   Sur l'exemple du véhicule, tu vas créer un objet Conducteur... Ce conducteur pourra conduire un véhicule (l'interface), mais lors de la programmation de l'objet, tu ne sauras pas quel est le type du véhicule... Ensuite, toi ou un autre programmeur pourra créer autant de type de véhicules que tu veux (voiture, moto, vélo, navette spatiale): si ils respectent l'interface, ils marcheront très bien avec ton conducteur...

c est de la genericite, comme en delphi ?
 
j ai suivit si ( en plus je suis venu te poser des questions apres ), le pb c est que j arrive pas a me faire a cette idee car pour moi on a forcement connaissance de type du vehicule, c est ca qui me choque.
deja que la genericite en delphi c etait pas mon fort .
 
parlons pour enumeration enumeration est une interface, vector et hashtable l implemente, elles sont les memes mehodes etc... mais quand tu fais enumeration E, e.hasMorEelement etc...
quand tu declare ton enumeration il sait que tu utilises unvecteur ou une hastable puis qu il fait aprti de ca declaration.
 
 
au fait l adresse de la doc java sur le net ? me souviens plus de ladresse j ai chercher sur le site de sun ou java.sun mais j ai pas trouver enfin me suis servit des tutoriaux.

 
Vector et Hashtable n'implementent pas Enumeration. Enumeration est en fait une sorte d'itérateur qui te permet de parcourir des collections d'éléments. Donc à chaque fois que tu as une Hashtable ou un Vecteur, voire une liste que tu aurais créé toi même, tu peux créer une Enumeration pour la parcourir.
 
Un exemple simple: Si tu as besoin d'une méthode qui te construit une drop down list en java, tu peux passer en argument de la méthode une Enumeration. Genre:
 
public String construitDropDown(Enumeration enum) {
  String str = "<SELECT>";
  while (enum.hasMoreElements()) {
    str+="<OPTION>"+(String)enum.nextElement();
  }
  return str;
}
 
Pour l'appel, tu pourras utiliser cette méthode avec une Hashtable, un Vector, voir ta Liste si elle est programmée correctement...
 
Par exemple   construitDropDown(monVct.elements());
ou encore construitDropDown(maHash.elements());
 
Bien entendu, l'interêt est d'utiliser une solution à un endroit, et l'autre à un autre endroit...
 
Plus clair?

ok j ai parfaitement pijer la .
enfin pas vraiment, y a bien une hisoire d interface la dedans ?
 
mais bon les interfaces...

Clarkent a écrit a écrit : ok j ai parfaitement pijer la . enfin pas vraiment, y a bien une hisoire d interface la dedans ?   mais bon les interfaces...

Enumeration, c'est une interface...
 
  putain il ne comprend rien  

BaNZai a écrit a écrit :   Enumeration, c'est une interface...     putain il ne comprend rien

ok mais ptain de merde faut bien qu ilk y est des classes qui l implemente non ?
 
je t ai dis que sur ce point j avais trop de mal.
 
bon je me retaprais le TP un jour ptetre que ca ira mieux.
m enfin dansla classe ils ont tous compris sauf qu ils sont incapable de l expliquer .

Clarkent a écrit a écrit : ok mais ptain de merde faut bien qu ilk y est des classes qui l implemente non ?   je t ai dis que sur ce point j avais trop de mal.   bon je me retaprais le TP un jour ptetre que ca ira mieux. m enfin dansla classe ils ont tous compris sauf qu ils sont incapable de l expliquer .

Tu utilises l'interface...
En realite, derriere Enumeration, il y aura une classe implementant cette interface pour les Vector, une autre pour les Hashtable, etc... Tu n'as pas la visibilite de ces implementations car elles ne presentent aucun interet pour toi. Par contre, elles sont utilisees par la classe Vector lorsque tu appelles elements() ...
 En gros, elements() sera comme ca
 
public Enumeration elements() {
  EnumerationSurVector esv = new EnumerationSurVector();
  //remplissage de EnumerationSurVector
  return esv;
}
 
Meme si EnumerationSurVector est construite, tu ne la verras jamais, vu que tu peux utiliser Enumeration!

L'interface est l'outil permettant d'avoir des classes le plus générique possible. Cette généricité permet une réutilisabilité optimum. Si tu as bien compris le role de l'objet cette notion d'interface est évidente ... un objet implémenté avec des données de type interfaces pourra travailler avec n'importe quel objet respectant celle-ci.
Ton objet pourra alors être utilisé dans plusieurs cas de figures avec des contraintes minimum.
L'exemple d'un objet travaillant avec des Enumeration est bon. Ton objet sera alors capable de travailler avec tout objet implémentant l'interface Enumeration ou permettant de retourner une énumération (Hashtable, Vector ...).

moi, y a un truc que je comprend pas, c: pourquoi on peut instancier Enumeration alors que c une interface !?

 
Ben tu l'implementes pas en tant qu'Enumeration, mais en faisant par exemple :
 
Enumeration e = new StringTokenizer("toto" );
 
(StringTokenizer implemente Enumeration)

Oui oui, on va dire ça comme ça ( !!
 
Je pense que ton compilo a du bien rire lorsque tu a ecris :
 
Enumeration l_MonEnum = new Enumeration();