Le polymorphisme en Java

bonjour ,je suis débutante en java
j'essai depuis ce matin de comprendre le plymorphisme en java mais j'arrive pas ,j'ai lu plusieurs documents mais j'arrive pas !!
est ce que vous pouvez me l'expliquer d'une maniére beaucoup plus simple sans un code ??? merci

Pour faire très simple, le polymophisme est une technique particulière d'héritage. Elle consiste, lorsqu'on hérite d'une classe, à redéfinir l'une des méthodes pour la spécialiser.

le plus simple je pense et de chercher "polymorphisme java" dans un moteur de recherche. Tu auras de nombreuses définitions et exemples.

Je me lance dans une explication et j'espère ne pas t'induire en erreur, car ce n'est pas vraiment facile à expliquer ...

En gros, c'est un concept objet qui consiste à pouvoir utiliser la "même" méthode sur des objets différents.

exemple banal. Tu prends une classe et des sous classes.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

class Animal { void deplacer() { System.out.println("Je bouge"); }   class Chien extends Animal { void deplacer() { System.out.println("Je marche"); } }   class Oiseau extends Animal { void deplacer(){ System.out.println("Je vole"); } }   class Pigeon extends Oiseau { void deplacer() { System.out.println("Je vole et en plus ... sur les passants"); } }

---

Sur toutes ces classes, tu peux donc appeler deplacer(). Le polymorphisme permet alors d'appeler la bonne méthode selon le type d'objet

Code:

---

1 2 3 4 5 6 7 8 9 10

public static void main(String[] args) {   Animal a1 = new Animal(); Animal a2 = new Chien(); Animal a3 = new Pigeon();   a1.deplacer(); a2.deplacer(); a3.deplacer(); }

---

et à l'exécution ça te donne :

Citation:

---

Je bouge
Je marche
Je vole et en plus ... sur les passants

---

Juste un petit complément qui peut être intéressant...

Généralement on définit la classe mère comme étant abstraite et on oblige les objets réels à définir leur comportement :

Tu trouveras également de nombreux exemples sur les figures (triangle, carré, ...).

Genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

abstract class Figure { private String couleur;   class Figure (String couleur) { this.couleur = couleur; }   public String getCouleur() { return couleur; }   abstract int getSurface(); }

---

Et après tu fais Triangle extends Figure, Carre extends Figure, ...

Pour reprendre l'exemple de in, cela est particulièrement intéressant avec les conteneurs (Vector, List etc.).
Image que tu veuilles mettre des instances dedans, des chiens, des pigeons etc. et que tu veuilles qu'ils se déplaces tous.
Pour cela, il te suffit de créer un conteneur d'animal :

Code:

---

1 2	List<Animal> lst=new ArrayList<Animal>();

---

et d'appeler la méthode deplacer sur chaque élément:

Code:

---

1 2 3 4

for(int i=0;i<lst.size();i++){ lst.get(i).deplacer(); // Appellera la méthode propre à chaque animal. }

---

Citation:

---

Envoyé par Duc Lebowski

Juste un petit complément qui peut être intéressant...

Généralement on définit la classe mère comme étant abstraite et on oblige les objets réels à définir leur comportement :

Tu trouveras également de nombreux exemples sur les figures (triangle, carré, ...).

Genre :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

abstract class Figure { private String couleur; public Figure (String couleur) { this.couleur = couleur; } public String getCouleur() { return couleur; } abstract int getSurface(); }

---

Et après tu fais Triangle extends Figure, Carre extends Figure, ...

---

Je te corrige une petite erreur.

Merci iohack ! Affectivement !

merci pou tous le monde ce géniale :ccool:

Code:

---

1 2 3 4 5

List<Animal> lst=new ArrayList<Animal>(); for(int i=0;i<lst.size();i++){ lst.get(i).deplacer(); // Appellera la méthode propre à chaque animal. }

---

est bien mieux comme ça :

Code:

---

1 2 3 4

List<Animal> animaux = new ArrayList<Animal>(); for (Animal animal : animaux) animal.deplacer(); // Appellera la méthode propre à chaque animal.

---

Plus simple, plus performant. Aucun inconvénient. Et encore, il doit y avoir plus performant que ArrayList, selon ce que fait le reste de l'appli.

De même,

Code:

---

1 2 3

void deplacer() { System.out.println("Je bouge"); }

---

moi je ferais, dans Animal :

Code:

---

1 2 3

Animal deplacer() { return this; }

---

puis, dans Pigeon :

Code:

---

1 2 3

Animal deplacer() { System.out.println("Je vole et en plus ... sur les passants "); return super.deplacer(); }

---

ce qui permet ensuite de faire des trucs genre

Code:

---

1 2	new Pigeon().deplacer().sePoser().grailler().roucouler().mourir();

---

Clair, performant, peu de boulot ensuite pour le GC, puisque tout passe par la pile.

Citation:

---

Envoyé par iohack

Pour reprendre l'exemple de in, cela est particulièrement intéressant avec les conteneurs (Vector, List etc.).
Image que tu veuilles mettre des instances dedans, des chiens, des pigeons etc. et que tu veuilles qu'ils se déplaces tous.
Pour cela, il te suffit de créer un conteneur d'animal :

Code:

---

1 2	List<Animal> lst=new ArrayList<Animal>();

---

et d'appeler la méthode deplacer sur chaque élément:

Code:

---

1 2 3 4

for(int i=0;i<lst.size();i++){ lst.get(i).deplacer(); // Appellera la méthode propre à chaque animal. }

---

---

stp,dans ce cas là ça sera afficher que le message "je bouge " tant que le tableau est n'est pas vide???

Et bien précisément, non...le message affiché pour chaque élément du tableau dépendra du type effectif de cet élément. Il faut juste comprendre qu'une variable a deux types en java:
1) le type de référence (c'est le type de la variable)
2) le type effectif: c'est le type de l'objet qui est dans cette variable à un instant donné.
Le type de référence te dit quelles méthodes seront visibles depuis cette variable (ex: toutes les méthodes publiques définies par Animal, + les méthodes protected si on utilise la variable depuis une classe dérivée d'Animal)
Le type effectif te dit quel sera le code effectivement utilisé quand tu appelles une méthode.

tu as plein d'objets dans ton troupeau et tu leur dis "arrétez-vous tous!"
comme ils sont Closeable ("fermable") il vont gentiment obéir ... chacun à sa manière, ces opérations de fermeture peuvent prendre des formes différentes (polymorphisme) , ces objets sont différents (et pas nécessairement apparentés par héritage), tu ne sais pas dans le détail ce qu'ils font mais ils vont le faire!
ce genre de généralisation est très puissante car elle permet aussi de bien isoler les modifications de code: tu fais la paye et pour chaque salarié tu demande le taux horaire, chaque objet Salarié (du Lampiste au PDG) te donnes son taux horaire, si celui du PDG est modifié (au hasard :D) seul le code de PDG est concerné pas celui de la paye!

Citation:

---

Envoyé par professeur shadoko

tu fais la paye et pour chaque salarié tu demande le taux horaire, chaque objet Salarié (du Lampiste au PDG) te donnes son taux horaire, si celui du PDG est modifié (au hasard :D) seul le code de PDG est concerné pas celui de la paye!

---

Sauf que là (à moins que le taux horaire des salariés de base soit une valeur fixe et celui du PDG calculé en fonction de son taux du jour de clearstream) tu n'as pas besoin de deux classes, donc ce n'est pas du polymorphisme...

Citation:

---

Envoyé par therwald

Sauf que là (à moins que le taux horaire des salariés de base soit une valeur fixe et celui du PDG calculé en fonction de son taux du jour de clearstream) tu n'as pas besoin de deux classes, donc ce n'est pas du polymorphisme...

---

ah bon :!:
cela prouve que je n'ai pas rendu mon exemple assez clair:
un Salarie à une méthode getTauxHoraire
les classes Lampiste, Grouillot, ContreMaitre, PetitChef, GrandChef, PDG ont chacune une méthode particulière (mais conforme au contrat "gatTauxHoraire" pour calculer le taux horaire en fonction de leur champs indice et de circonstances propres à leur métier.

Ces codes sont mis et modifiés dans les classes correspondantes.
La Paye de ne pose pas de question et elle demande à chaque instance conforme au "contrat" Salarie de lui donner son taux horaire ....

C'est plus clair?

Effectivement là on voit mieux la variation dans l'algorithme, donc à mon sens c'est plus clair.