Heritage multiple en java [Résolu]
sgassama
- Messages postés
- 23
- Date d'inscription
- mercredi 10 août 2011
- Dernière intervention
- 1 novembre 2012
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
A voir également:
- Destructeur java
- Destructeur en java - Meilleures réponses
- La classe scanner - Conseils pratiques - Java
- Java la methode pour inverser un string ✓ - Forum - Java
- Test de recrutement classique autant qu'Ingénieur ou Architecte .Net avec quelques notions Java - Conseils pratiques - C# / .NET
- Tutoriel pour la création d'une petite application « Annuaire » en Java. - Conseils pratiques - Java
- Java et le bytecode : comprendre le résultat de vos compilations - Conseils pratiques - Java
11 réponses
Meilleure réponse
Salut
c'est justement la grande force de la programmation orientée objet...
Java ne supporte pas le multiple héritage (comme le C++ par exemple qui lui le permet).
Pour pallier à ce petit problème, on utilise les interfaces..
Celà permet de définir éventuellement un autre comportement que les membre d'une même famille de la classe..
les interfaces contiennent effectivement des méthodes non implémentées. On peut dire en fait qu'une classe qui implémente une interface, signe une sorte de contrat avec les autres objets suscpetible de faire appel à elle. Ce contrat est simple, il s'agit d'utiliser une signature de méthode "générique" et surtout de renvoyer le résultat (si il y en a) sous un format bien défini). Ce qui veut dire que tous les objets qui implémentent une interface, signent le même contrat.
prenons un exemple
une entreprise...
il existe une superclasse Abstraite Employé... cette classe pour simplifier possède une méthode abstraite public void bosse() qui ne contient pas de code. en effet, en fonction de leur travail spécifique le code sera différent (c'est un peu du polymorphisme ça...). Cette classe posséde une autre méthode public void pointe() qui elle possède du code parceque tous les employés pointe leurr arrivée au boulot de la même manière..
Toutes les instances d'Employé hériteront donc de la méthode pointe() mais devront définir le corp de la méthode bosse...
Cependant certains employés auront en plus une fonction de commandement, les chefs... qui eux en plus des autres doivent "commander".
Pour réussir ce challenge, les employés chefs vont implémenter une interface (l'interface TheBoss qui contient une méthode non implémenté public void dirige(). Il est clair que chaque chef dirige en fonction de son rang dans la hiérarchie et que le corps de la méthode sera différent pour chaque chef..
pigé?
c'est justement la grande force de la programmation orientée objet...
Java ne supporte pas le multiple héritage (comme le C++ par exemple qui lui le permet).
Pour pallier à ce petit problème, on utilise les interfaces..
Celà permet de définir éventuellement un autre comportement que les membre d'une même famille de la classe..
les interfaces contiennent effectivement des méthodes non implémentées. On peut dire en fait qu'une classe qui implémente une interface, signe une sorte de contrat avec les autres objets suscpetible de faire appel à elle. Ce contrat est simple, il s'agit d'utiliser une signature de méthode "générique" et surtout de renvoyer le résultat (si il y en a) sous un format bien défini). Ce qui veut dire que tous les objets qui implémentent une interface, signent le même contrat.
prenons un exemple
une entreprise...
il existe une superclasse Abstraite Employé... cette classe pour simplifier possède une méthode abstraite public void bosse() qui ne contient pas de code. en effet, en fonction de leur travail spécifique le code sera différent (c'est un peu du polymorphisme ça...). Cette classe posséde une autre méthode public void pointe() qui elle possède du code parceque tous les employés pointe leurr arrivée au boulot de la même manière..
Toutes les instances d'Employé hériteront donc de la méthode pointe() mais devront définir le corp de la méthode bosse...
Cependant certains employés auront en plus une fonction de commandement, les chefs... qui eux en plus des autres doivent "commander".
Pour réussir ce challenge, les employés chefs vont implémenter une interface (l'interface TheBoss qui contient une méthode non implémenté public void dirige(). Il est clair que chaque chef dirige en fonction de son rang dans la hiérarchie et que le corps de la méthode sera différent pour chaque chef..
pigé?
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
109 internautes nous ont dit merci ce mois-ci
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Bonjour,
En effet pas d'héritage multiple en java mais les interfaces ne permettent pas de régler le problème.
Pour t'en sortir, il faut utiliser la composition virtuellement couplée avec un design pattern Decorator :
Alors, c'est pas top parce que tu écris beaucoup de code pour rien mais ça marche comme de l'héritage multiple.
En effet pas d'héritage multiple en java mais les interfaces ne permettent pas de régler le problème.
Pour t'en sortir, il faut utiliser la composition virtuellement couplée avec un design pattern Decorator :
public interface IInterface {
public void methode();
}
public class Classe1 implements IInterface(){
@Override
public void methode(){
//corps de la méthode
}
}
public class Classe2 extends Thread implements IInterface {
private IInterface wrap;
public Classe2(){
wrap = new Classe1();
}
@Override
public void methode(){
wrap.methode();
}
}
Alors, c'est pas top parce que tu écris beaucoup de code pour rien mais ça marche comme de l'héritage multiple.
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
109 internautes nous ont dit merci ce mois-ci
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Pour le design pattern Decorator, le principe est le suivant, je reprend l'exemple de pointColore, on aimerait bien que PointColore hérite de Point et de Couleur :
Mais en java, pas d'héritage multiple, on peut donc faire cela :
Je te donne la classe PointColore :
+-------------+
| PointColore |
+-------------+
+-------------+
^ ^
/ \
(héritage) / \ (héritage)
/ \
+-------------+ +-------------+
| Point | | Couleur |
+-------------+ +-------------+
| x | | valeur |
| y | +-------------+
+-------------+
Mais en java, pas d'héritage multiple, on peut donc faire cela :
+-------------+
| PointColore |
+-------------+---+
+-------------+ |
| getValeur() | |
+-------------+ |
^ \ 0..* |
/ \ | (implémentation)
(héritage) / \ |
/ \ 1 V
+-------------+ +-------------+
| Point | | ICouleur |
+-------------+ +-------------+
| x | +-------------+
| y | | getValeur() |
+-------------+ +-------------+
^
| (implémentation)
|
+-------------+
| Couleur |
+-------------+
| valeur |
+-------------+
| getValeur() |
+-------------+
Je te donne la classe PointColore :
public class PointColore extends Point implements ICouleur {
private ICouleur couleur;
public PointColore(){
couleur = new Couleur();
}
@Override
public Color getValeur(){
return couleur.getValeur();
}
}
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
109 internautes nous ont dit merci ce mois-ci
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Les annotations @Override sont des indications que tu donnes au compilateur, par exemple, si tu utilises @Override, cela veut dire que la méthode qui suit est une méthode que tu vas redéfinir, elle doit donc être soit définie dans une classe mère soit définie dans une interface implémentée (depuis java6).
Mais ces annotations ne servent à rien lors de l'exécution.
Mais ces annotations ne servent à rien lors de l'exécution.
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
109 internautes nous ont dit merci ce mois-ci
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Et enfin pour le Thread, décidément, tu poses beaucoup de questions !! Si tu veux lancer un traitement en arrière plan, tu peux faire ceci :
Pour lancer le traitement définit dans la méthode run, il faut appeler la méthode start de la classe Thread :
new Traitement().start()
la méthode run lance le traitement dans le thread courant
public Traitement extends Thread {
@Override
public void run(){
// Définition du traitement à lancer en arrière plan
}
}
Pour lancer le traitement définit dans la méthode run, il faut appeler la méthode start de la classe Thread :
new Traitement().start()
la méthode run lance le traitement dans le thread courant
Quelques mots de remerciements seront grandement appréciés. Ajouter un commentaire
109 internautes nous ont dit merci ce mois-ci
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
- Messages postés
- 2116
- Date d'inscription
- samedi 8 novembre 2003
- Statut
- Messages postés
- 23
- Date d'inscription
- mercredi 10 août 2011
- Dernière intervention
- 1 novembre 2012
LE@DEBUTANT
bonsoir et merci a tous
j'ai un peu compris la les explication de otobox mais pas assez celle de julien39
je n'ai pas bien compris votre deuxieme message consernant le threads
et la classe interne comment creer une classe interne dans une autre classe et quelle est l'utilité des threads et @override?
Pour le threads le prof nous a bien expliqué qu'il permettait l'execution de programmes en arriere plan mais j'aimerai en savoir plus+++++
mci a tous pour vos reponses
bonsoir et merci a tous
j'ai un peu compris la les explication de otobox mais pas assez celle de julien39
je n'ai pas bien compris votre deuxieme message consernant le threads
et la classe interne comment creer une classe interne dans une autre classe et quelle est l'utilité des threads et @override?
Pour le threads le prof nous a bien expliqué qu'il permettait l'execution de programmes en arriere plan mais j'aimerai en savoir plus+++++
mci a tous pour vos reponses
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Je ne suis pas entièrement d'accord avec toi GodConan, oui, on peut se passer de l'héritage multiple mais il y a de nombreux cas pour lesquels je regrette vraiment que ce ne soit pas possible en java.
Par exemple si tu as une classe Point et une classe Couleur et que tu veux créer une classe PointColore et bien, tu es obligé de faire de la duplication ou d'utiliser des pattern alors que le concept est simple pourtant.
Mais bon, ok, on peut s'en passer
Par exemple si tu as une classe Point et une classe Couleur et que tu veux créer une classe PointColore et bien, tu es obligé de faire de la duplication ou d'utiliser des pattern alors que le concept est simple pourtant.
Mais bon, ok, on peut s'en passer
- Messages postés
- 6450
- Date d'inscription
- mardi 8 mars 2005
- Dernière intervention
- 17 mai 2018
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.