Bonjour
 
Est ce possible de marquer une methode de maniere a ce qu'elle n'apparaisse pas dans la Javadoc?
 
Merci

question, pq veux tu faire ca? Si tu veux que la méthode ne soit pas publique, déclares la privée ... mais bon c'est un peu prendre le problème à l'envers.
 
Donc pq veux tu faire ca?

dans ma classe repere, j'implemente paint et elle apparait dans la javadoc, alors que ce n'est pas une fonction de ma classe a moi!
 
je la declare kom ca :
public void paint(Graphics g)
 
alors fodrait ke je mette
private void paint(Graphics g)
 
?

je ne peux pas utiliser cette astuces la, je n'ai pas le droit de restraindre les droit de la fonction paint

ben si c'est une fonction de ta classe à toi : tu l'implémentes

donc pour vous elle doit apparaitre dans la javadoc?

 
bin tu l'implémentes et tu voudrais que ca n'apparaisse nul part ... Je ne suis pas ta logique ...

As tu compris le but de l'implementation d'interface ?

je pense oui
on redefinit le contenu de la methode tout en gardant son nom!
 
enfin paint ce n'est pas une méthode que l'on appelle, c'est java qui l'appelle c'est pour cela que je ne voulais pas qu'elle apparaisse.
 
mais c'est vous les pro!

 
Alors tu n'as pas compris.
 
Tu ne redefinis rien du tout en implementant une interface. Les interfaces sont des contrats, en implementant une interface tu assures les utilisateurs de ta classe ainsi que la VM de l'existance de telles methodes avec telles signatures. Le code de ces methodes est laisse a ta discretion.  
 
C'est la qu'intervient l'utilite de la javadoc.
 
Si tu implementes une interface la javadoc l'indiquera (implements patati, patata...) Mais personne ne sait quelle est la mise en oeuvre que tu as adopte. On sait juste que tu la methode existe. Les infos concernant la mise en oeuvre (algos, etc...), les problemes potentiels (perfs, portablite, etc...), etc c'est a toi de les indiquer dans la javadoc. Si tu ne fais rien c'est la doc de l'interface qui est prise, elle ne gene en rien du tout et ca n'a aucun sens de l'enlever.
 
La javadoc est la pour informer l'utilisateur de l'API pas pour l'embrouiller. Tu implemente, la javadoc l'indique. Imagine toi que je te dise "je passe ce contrat avec toi mais les points 2 a 5 sur les 20 chiffres ne sont pas du tout indiques..." tu reagirais comment ?
 
S'il y a des fonctionnalites qui doivent rester cachees a l'utilisateur lambda (et la on entre dans les details de mise en oeuvre) tu peux faire une JD separee avec un autre niveau de visibilite (documentation des methodes privees par exemple) mais ceci reste marginal et ne s'applique evidemment pas aux interfaces et a leur implementation (si elles doivent etre cachees elles sont privees donc ne font pas partie d'une interface donc tu n'sa as ton probleme).
 
Pour revenir aux interfaces, leur but, contrairement a l'heritage, (ceci vu que l'on est dans un contexte d'heritage simple) est juste de *garantir* des fonctionnalites. Ceci permet de ne pas entrer en conflit avec l'heritage et donc de laisser le developpeur un choix total quant a la mise en oeuvre qu'il va adopter (et donc d'utiliser eventuellement des classes issues d'un autre arbre hierarchique).
 
Bon j'ai rdv a+
 

P.S. J'espere que ca t'eclaire

bon jviens de lire, effectivement de ce point de vue la methode paint DOIT apparaitre dans la javadoc, pour que l'on sache que j'implemente paint!
 
Merci de m'avoir consacrer du temps
 
je vais rechercher de plus ample informations sur les intefaces, les classes abstraites et si j'ai des questions je reviendrais.
 
 
Par contre la j'ai 3 classes qui ne peuvent etre utilisées l'une sans l'autre, y a t-il un moyen de les regrouper?
 
 
Merci

sans plus d'élément on peut vraiment pas répondre à ta question !

Dans un package ?
 
Désolé.  

 
j'ai voulu mettre ca mais j'ai hésité