Histoire d'heritage. - Java - Programmation
Marsh Posté le 04-06-2005 à 20:26:18
C'est pas vraiment le but en fait ... y aura aucun polymorphisme avec des objets dont les classes n'appartiennent pas à la meme hierarchie d'heritage.
Marsh Posté le 04-06-2005 à 20:27:32
ca m'a l'air bizarement fagoté ton histoire
Marsh Posté le 04-06-2005 à 20:29:08
chrisbk a écrit : ca m'a l'air bizarement fagoté ton histoire |
Bein oué desfois c'est compliqué ...
Marsh Posté le 04-06-2005 à 20:29:52
Rien compris.
Mais la solution pragmatique est :
Code :
|
Et bien sûr tu ne déclares la méthode getCours que dans la classe SupportCours puisqu'elle n'a de sens que dans cette classe.
Marsh Posté le 04-06-2005 à 20:31:39
je propose meme
Code :
|
Marsh Posté le 04-06-2005 à 20:34:02
L'appel de la methode ce fait en fonction du type reel et non du type declaré ... sert a rien ton cast.
Marsh Posté le 04-06-2005 à 20:34:39
Bon je vais tester
Marsh Posté le 04-06-2005 à 20:35:50
hehu ma solution c'etait pour la deconne hein ?
Marsh Posté le 04-06-2005 à 20:36:40
Chronoklazm a écrit : L'appel de la methode ce fait en fonction du type reel et non du type declaré ... sert a rien ton cast. |
Mais bien sûr.
Marsh Posté le 04-06-2005 à 20:45:45
Bein oué, mais la y a une interface donc ... apparament vous avez raison, faut caster.
Mais pourtant y a surement un moyen de le faire sans cast, sinon ca serai pas dans un sujet d'examen. Genre la declarer en abstract dans l'interface et dans DocumentImpl ... et la redefinir dans SupportCours et dans Tp en faire une bidon qui renvoi null.
Marsh Posté le 04-06-2005 à 20:54:50
C'est quoi l'intérêt de déclarer une méthode abstract dans une interface (puisque visiblement c'est possible) ?
Et pourquoi diable voudrais-tu déclarer une méthode dans une interface où ça n'a pas de sens ?
Marsh Posté le 04-06-2005 à 20:59:40
- Ca je sais pas .. peut etre pour la portée.
- Pour faire des Document doc; puis doc.getCours(). (pour moi si c'est dans un exam, ca a un sens )
Marsh Posté le 04-06-2005 à 23:40:32
nraynaud a écrit : pattern Visitor |
Merci à toi et ta grande clarté.
Marsh Posté le 05-06-2005 à 00:08:50
Chronoklazm a écrit : Merci à toi et ta grande clarté. |
et encore, t'as du bol ! à une époque, il ne mettait aucun smiley
Marsh Posté le 05-06-2005 à 00:46:14
de rien, j'aime aider les débutants.
Marsh Posté le 05-06-2005 à 00:50:23
bon explique-nous un peu les traitements qui impliquent de regarder les cours dans un Document ... On va tenter de mettre ça à plat.
Marsh Posté le 05-06-2005 à 01:42:26
Bein en fait un Support de Cours est lié a un cours (un objet Cours quoi), donc on aura un attribut privé cours dans la classe SupportCours (+ un accesseur), ce qui n'est apparament pas le cas pour un TP. En fait un Tp illustre un Support de cours ... donc pour connaitre le cours auquel est lie un Tp on passera par le SupportCours d'un Tp.
DocumentImpl implemente Document ... SupportCours et Tp herite de DocumentImpl.
Enfin bon, une prise de tete pas possible pour pas grand chose quoi.
Donc la vrai question serai : Peut on implementer certaine methodes d'une Interface ... une selection plutot que tout ?
Et aussi, toi qui adore aider les debutants Ca sert a quoi de declarer des methodes abstract dans une Interface, ca a une utilité concrete ?
Marsh Posté le 05-06-2005 à 01:55:46
Chronoklazm a écrit : Ca sert a quoi de declarer des methodes abstract dans une Interface, ca a une utilité concrete ? |
ca n'a aucun sens : une interface ne fait que de déclarer des méthodes => elles sont toutes à implémenter (ce qui est la signification d'abstract) => pour peu qu'on puisse déclarer une méthode d'une interface abstract (ce dont je doute), c'est stupide.
Chronoklaz>
ta méthode getCours n'a rien à faire dans l'interface Document.
Marsh Posté le 05-06-2005 à 01:56:52
benou a écrit : ca n'a aucun sens ... |
Mais c'est possible de le faire (même si ça n'a visiblement aucun effet).
Marsh Posté le 05-06-2005 à 02:00:29
Chronoklazm a écrit : Bein en fait un Support de Cours est lié a un cours (un objet Cours quoi), donc on aura un attribut privé cours dans la classe SupportCours (+ un accesseur), ce qui n'est apparament pas le cas pour un TP. En fait un Tp illustre un Support de cours ... donc pour connaitre le cours auquel est lie un Tp on passera par le SupportCours d'un Tp. |
La vraie question c'est : quel est le rapport entre la première partie de ton message et la question que tu poses à la fin ?
Il est où le problème ? Tu veux implémenter certaines méthodes d'une interface est pas d'autres ? Rigoureusement c'est pas possible. En pratique il suffit de les définir vide.
A partir de là il n'y a que toi qui sais ce que tu as le droit de faire ou non, ou alors file le vrai sujet, donne une solution possible et on te dit si ça nous paraît correct ou pas. Je vois que ça.
Marsh Posté le 05-06-2005 à 10:38:40
benou a écrit : ... |
Je suis d'accord mais pourtant :
Citation : |
Marsh Posté le 05-06-2005 à 10:46:37
Quel est le rapport : Bein j'ai une interface et dans une classe (SupportCours) qui l'implemente je veux redefinir une methode, et dans une autre classe qui l'implemente (Tp) je n'en veux pas ... une selection quoi.
Pour le sujet : http://deptinfo.unice.fr/~grin/mes [...] nonce.html
Pour la solution : J'en ai deja une ... je cherchai juste a capté comment faire pour ne pas ecrire de methode getCours dans la classe Tp.
Marsh Posté le 05-06-2005 à 14:20:56
Le schéma est idiot en lui-même. Pour avoir envie d'appeler getCours qui n'a de sens que dans SupportCours, il faut savoir à l'avance (ou le tester à l'exécution) que "doc" sera en fait un SupportCours. Et dans les deux cas, ça passe par un cast.
Si tu te mets à déclarer getCours dans Document pour pas avoir à faire de cast dans ce cas tu vas devoir déclarer tous les accesseurs de toutes les classes qui implémentent ton interface, ce qui est idiot (de toutes façons c'est déjà idiot de le faire pour un seul accesseur). Le sujet précise bien en plus "// doc est un support de cours ou un TP, ou tout autre document".
Marsh Posté le 05-06-2005 à 14:38:08
benou a écrit : ca n'a aucun sens : une interface ne fait que de déclarer des méthodes => elles sont toutes à implémenter (ce qui est la signification d'abstract) => pour peu qu'on puisse déclarer une méthode d'une interface abstract (ce dont je doute), c'est stupide. |
c'est pas exactement ça.
En fait toutes les méthodes d'une interface sont implicitement "abstract" et donc le mot-clef devient optionnel dans les interfaces.
par contre :
Citation : For compatibility with older versions of the Java platform, it is permitted but discouraged, as a matter of style, to redundantly specify the abstract modifier for methods declared in interfaces. |
http://java.sun.com/docs/books/jls [...] html#78651
chrono > je réponds dans un autre post à la vraie question ...
Marsh Posté le 05-06-2005 à 14:56:18
chrono > c'est très très con :
Code :
|
(je donne la réponse parce que je pense qu'il est passé à côté)
ce qu'il veut dans cette question, c'est tous les documents associé à un cours.
Marsh Posté le 05-06-2005 à 15:17:33
Ah ouais ptain ... on aura forcement une methode getCours() dans Tp et dans tout document.
Merci les gens !
Marsh Posté le 04-06-2005 à 19:44:29
Bonjour, voila j'aimerais resoudre un petit probleme d'heritage ...
J'ai :
- une interface Document
- une classe abstract DocumentImpl qui implemente Document
- une classe SupportCours qui herite de DocumentImpl
- une classe Tp qui herite de DocumentImpl
Sachant qu'un SupportCours contient un attribut privé "cours" , j'aurais donc un accesseur getCours()..
Je voudrais pouvoir faire des :
Or pour que ca marche getCours() doit etre declaré dans l'interface Document, donc je la declare en abstact dans Document, puis pareil dans DocumentImpl et dans SupportCours finallement je la redefini.
Le probleme est que je doit aussi la redefinir dans Tp, or dans Tp j'en ai pas besoin ...
Comment puis-je eviter d'avoir cette methode dans la classe Tp ??? La declarer abstract me parrait un peu sale. (en plus ca marche pas)
Merci.
Message édité par Chronoklazm le 04-06-2005 à 19:46:39
---------------
Scheme is a programmable programming language ! I heard it through the grapevine !