Merci de mentionner notre outil - DocFlex/Javadoc
Soit dit en passant, à l'exclusion des classes simplement et les membres ne sont pas toute l'histoire. Le JavaDoc généré doit être cohérent après cela.
Par exemple, supposons que nous avons la situation suivante:
- classe
C1
étend la classe C2
- classe
C2
étend la classe de classe C3
C3
contient une méthode publique m()
- qui est censé être documenté
Maintenant, supposons que la classe C3
doit être exclue de la documentation. Que va-t-il se passer avec la méthode m()
? Il doit être indiqué dans la documentation comme déclaré dans la classe C2
! Ensuite, pour la classe C1
, m()
doit apparaître comme hérité de la classe C2
(plutôt que de la classe C3
, comme c'est actuellement le cas dans le code).
La même situation se présente avec les champs, ce qui est en réalité encore plus compliqué, car les champs avec des noms identiques ne se surchargent pas mais s'observent mutuellement.Par exemple
- classe
C1
étend la classe C2
- classe
C2
implémente l'interface I
- classe
C2
contient un champ privé F
- Interface
I
contient un champ public F
- qui pourrait être documenté
Supposons que l'interface I
doit être exclue de la documentation. Que faire avec le champ I.F
? En fait, rien! Il ne devrait pas figurer dans la documentation car il est masqué par C2.F
, qui est privé et, par conséquent, doit être invisible.
Est-ce que le simple réglage (délégation) de la norme Doclet résout de tels problèmes?
Notre outil fait!
Je ne l'ai pas essayé, mais ce produit a des exclusions flexibles, et permet aux classes d'être exclues en fonction de l'annotation. Voir http://www.filigris.com/products/docflex_javadoc/templates.php – mdma