Discussion :

[Ikit]

Bonjour !
Comme l'indique le titre, j'arrive pas à comprendre ce que c que le polymorphisme, a quoi ça sert etc ...

pour interface, j'ai regardé la faq, mais ça ne m'as pas plus éclairé :s ....



Pour ce qui est du polymorphisme, d'aprés ce que j'ai compris dans mon cours, en gros:

on a une classe A
on a une classe B qui hérite de A

Alors on peu définir un objet A en faisant :
A a = new B( ... ) ;

ou l'inverse,... je sais plus

bref, où est l'intéret ... si c bien de ça qu'il s'agit !?
et ça ne se limite qu'à ça le polymorphisme ? ou il y a autre chose



Pour ce qui est des interfaces, grossomodo je pense avoir compris qu'il s'agit de permettre a une classe d'hérité de plusieures autres non ?
du moins c ce que je pensais avoir compris dans le cours, mais quand j'ai lus la faq ... :o !
je me trompe ou ça n'a rien à voir ... j'ai rien compris à ce que "vous" dites dedans
quelqu'un aurait-il la bonté de m'expliqué ce que c'est

[bulbo]

L'avantage de pouvoir faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
A a = new B();

C'est que cela permet d'implementer dans A un traitement qui sera commun a toutes les classes derivant de A et que dans ce cas on n'a pas besoin de sepreoccuper du type effectif de l'objet.

Une interface ne sert pas a faire des extends de plusieurs objets mais de definir des interfaces qu'implementera une classe (des comportements si tu preferres).

De la meme maniere que pour le polymorphisme cela permet de traiter toutes les classes implementant l'interface comme si c'etait l'interface.

Par exemple qq soit la classe implementant un ActionListener il suffit de faire:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
((ActionListener) monObject).actionPerformed(event):

pour appeler la methode actionPerformed de cet objet.

Bulbo

[Cold Hand]

on a une classe A
on a une classe B qui hérite de A

Alors on peu définir un objet A en faisant :
A a = new B( ... ) ;

C'est bien dans ce sens là, mais ça, c'est de l'héritage. Si tu veux schématiser, un objet d'une sous-classe est toujours un objet d'une super classe, mais pas l'inverse (Un Homme est un EtreHumain, mais un EtreHumain n'est pas toujours un Homme) A quoi ça sert ? A tout A écrire du code plus simplement, plus proprement, à concevoir un projet de manière plus claire, etc ! Tout ça se fait principalement en "surchargeant" des méthodes : en gros, je suis une sous-classe, je sais faire tout ce que ma super-classe sait faire, mais également un peu plus et de manière plus précise. Par exemple, la classe ArrayList en Java (en gros, c'est un vecteur dynamique). Si tu définis MyArrayList extends ArrayList, d'emblée ta classe sait utiliser tout ce que ArrayList propose comme methode. Les intérêts sont multiples... suppose que tu aies besoin d'un vecteur, mais que celui-ci gère l'ajout différement (du sytle, au lieu d'ajouter les Objets à la fin, il les insère au début), il te suffit de redéfinir la methode add et le tour est joué. Deuxième avantage, si toutes tes autres classes sont définies comme travaillant avec un ArrayList, pas besoin de tout réécrire. Comme MyArrayList EST un ArrayList aussi, ton code marche toujours. Bref, je vais pas m'étendre d'avantage, je pense que t'as compris

Pour ce qui est des interfaces, grossomodo je pense avoir compris qu'il s'agit de permettre a une classe d'hérité de plusieures autres non ?

Non, pas exactement L'héritage multiple est interdit en Java. Une Interface sert juste à définir aux yeux de ton programme et des développeurs ce que ton objet est CAPABLE de faire. Si elle implémente Comparable, elle DOIT nécessairement proposer une methode compareTo. Si elle implémente Clonable, elle doit fournir clone(), etc. L'avantage par rapport à l'héritage c'est qu'elle peut implémenter autant d'Interface que tu veux. L'inconvéniant, c'est que tu dois implémenter toutes les méthodes toi-même (pour l'exemple plus haut, tu aurais pu définir MyArrayList comme implémentant List, mais tu aurais dû te retaper toutes les methodes de List, donc l'héritage était plus intéressant).

Je dois filer au boulot, si y a encore des points d'ombre, hésite pas

[Ikit]

C'est bien dans ce sens là, mais ça, c'est de l'héritage. Si tu veux schématiser, un objet d'une sous-classe est toujours un objet d'une super classe, mais pas l'inverse (Un Homm [... ] t, pas besoin de tout réécrire. Comme MyArrayList EST un ArrayList aussi, ton code marche toujours. Bref, je vais pas m'étendre d'avantage, je pense que t'as compris

ok ok ... mais alors pourquoi définir a comme avec new B()

quand on fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

A a = new B( ...);

a c'est un objet de type A ou de type B ?
a il a les méthodes de B ou A ?

C'est que cela permet d'implementer dans A un traitement qui sera commun a toutes les classes derivant de A et que dans ce cas on n'a pas besoin de sepreoccuper du type effectif de l'objet.

? j'ai du mal à suivre
en faisant A a = new B on implémente qq chose dans A ?

De la meme maniere que pour le polymorphisme cela permet de traiter toutes les classes implementant l'interface comme si c'etait l'interface.

ok
pour interface je crois que j'ai compris ^^
si on a 3 classe A B C, qui n'ont rien a voir mais qui utilise la même interface, qui propose la méthode affiche();
on pourra faire a.affiche(); comme b.affiche(), de la même manière que c.affiche();
(mais à ce moment là, on peux trés bien se passer de l'interface alors puisqu'il faut redefinir la méthode affiche ds chaque classe ...
c jute pour la lisibilité ?

mais pourquoi tu dis :"de la même manière que pour le polymorphisme ?"
je vois pas où est le point commun ?

[Cold Hand]

ok ok ... mais alors pourquoi définir a comme avec new B()

Tu as beau être un EtreHumain (et donc hériter des caractères communs aux êtres humains) au moment de ta naissance tu est forcemment un Homme ou une Femme (en Java on dirait que EtreHumain est abstract, mais ne comppliquons pas...) Cela te permet de profiter des redéfinitions de la classe B. Supposons que tu aies une méthode toString() dans A qui soit super basique et que tu la surcharges dans B pour qu'elle soit super jolie. Quand tu passes ton objet à une méthode qui utilise des objets de type A, elle utilisera toutes les méthodes de A, dont toString(), mais le résultat sera le toString() super joli de B

a c'est un objet de type A ou de type B ?
a il a les méthodes de B ou A ?

1) Les deux
2) Les deux

C'est le principe de l'héritage. Un Homme est un EtreHumain et donc un Animal et donc un EtreVivant et donc un Objet etc etc. C'est la hierarchie des classes... Comme Animal propose la méthode respirer(), tous ses enfants en disposent aussi et certains enfants la redéfinissent (comme la classe Poisson par exemple, mais un Poisson n'en reste pas moins un Animal)

en faisant A a = new B on implémente qq chose dans A ?

Non, mais tu utilise dans B ce que tu as implémenté dans A.

on pourra faire a.affiche(); comme b.affiche(), de la même manière que c.affiche();
(mais à ce moment là, on peux trés bien se passer de l'interface alors puisqu'il faut redefinir la méthode affiche ds chaque classe ...
c jute pour la lisibilité ?

C'est ça. Et non, on ne peut pas s'en passer (ou plutôt on peut parfois s'en passer, mais c'est 1) moche et 2) pas efficace du tout). A, B et C implements Affichable (comme dans ton exemple) et affiche() est en réalité un System.out.println() d'une des valeurs de A, B ou C. Si je veux faire une methode callAffiche(), je fais quoi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
public void callAffiche(Affichable affichableObject){
  System.out.print("Mon objet s'affiche : ");
  affichableObject.affiche();
}

Maintenant, supprime l'Interface.......

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
public void callAffiche(A affichableObject){
  System.out.print("Mon objet A s'affiche : ");
  affichableObject.affiche();
}
 
public void callAffiche(B affichableObject){
  System.out.print("Mon objet B s'affiche : ");
  affichableObject.affiche();
}
 
public void callAffiche(C affichableObject){
  System.out.print("Mon objet C s'affiche : ");
  affichableObject.affiche();
}

Tu vois le problème... ?

Le point commun avec le polymorphisme vient du fait que pour une signature identique, le résultat est identique. C'est INDISPENSABLE si tu bosses avec d'autres codeurs... chacun code d'une manière différente, mais si tout le monde se met d'accord sur un set d'Interfaces, peut importe l'implémentation, tu SAIS de quelles méthodes tu disposes, même si ce n'est pas toi qui développe la Classe en question...

[Regis.C]

En tout cas c epost est super interressant.