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.

Pourquoi ne pas déclarer doc_1 de type SupportCours ?

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.

ca m'a l'air bizarement fagoté ton histoire

 
Bein oué desfois c'est compliqué ...

Rien compris.
 
Mais la solution pragmatique est :
 

 
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.

je propose meme  
 
 

 
L'appel de la methode ce fait en fonction du type reel et non du type declaré ... sert a rien ton cast.

Bon je vais tester

hehu ma solution c'etait pour la deconne hein ?

 
Mais bien sûr.

 
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.

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 ?

- 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   )

pattern Visitor

 
Merci à toi et ta grande clarté.

et encore, t'as du bol ! à une époque, il ne mettait aucun smiley

de rien, j'aime aider les débutants.

bon explique-nous un peu les traitements qui impliquent de regarder les cours dans un Document ... On va tenter de mettre ça à plat.

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 ?  

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.

 
Mais c'est possible de le faire (même si ça n'a visiblement aucun effet).

 
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.

 
Je suis d'accord mais pourtant :
 

 
 
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.
 

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".

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 :

http://java.sun.com/docs/books/jls [...] html#78651
 
chrono > je réponds dans un autre post à la vraie question ...

chrono > c'est très très con :  

 
(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.

Ah ouais ptain ... on aura forcement une methode getCours() dans Tp et dans tout document.
 
Merci les gens !