2009-12-18 11 views
5

Esiste un'annotazione per dichiarare che un certo metodo non verrà incluso in JavaDocs anche se pubblico?Annotazione per disabilitare JavaDocs

Qualcosa di simile:

@nojavadocs 
public void foo(){ 
//... 
} 

P.S. Capisco il punto qui sull'API, ma i metodi sono semplicemente "non supportati". Funzionano (e devono essere pubblici per l'accesso da altri pacchetti), ma non vogliamo preoccuparci di documentarli e di rispondere a domande su come usarli quando le loro funzionalità non sono rilevanti per gli scenari di utilizzo supportati. Un buon design potrebbe significare spostarli in un'altra classe, ma si riferiscono logicamente ai dati della classe.

risposta

4

Non se si utilizza lo strumento JavaDocs di Sun.

Hanno a feature request per questo, ma è stato a bassa priorità dal 1997.

È possibile scrivere una doclet personalizzato per superare questo, o utilizzare uno strumento di terze parti (DocFlex o tali).

+1

Buono a sapersi c'è una richiesta di funzionalità - almeno non sono l'unico manichino a chiedere questo :-) –

4

Sì ... ma non in senso positivo (disporre di metodi pubblici che non sono realmente "pubblici" non è una buona pratica di progettazione).

È possibile seguire il suggerimento indicato in this thread e contrassegnare il metodo utilizzando @deprecated quindi quando si esegue javadoc utilizzare l'opzione -nodeprecated.

Modifica: come altri hanno notato, questo è non una linea di condotta auspicabile. Questo risolverà il tuo problema, ma hai davvero bisogno di ripensare perché vuoi nascondere il metodo - data una versione compilata del tuo codice qualcuno sarà ancora in grado di vedere la tua funzione; nasconderlo nella documentazione non nasconde di fatto il metodo. Intendo davvero sottolineare che le qualificazioni private, public e protected hanno un significato che dovresti considerare e utilizzare in modo efficace. Non esiste un metodo "nascosto" public.

+0

Questo funzionerà, ed è una soluzione intelligente, ma è un problema in quanto si sta abusando dell'annotazione della deprecazione, quindi il codice non corrisponde a ciò che "significa". Per lo meno commenterei i metodi e spiegherò chiaramente perché stavo facendo qualcosa di strano. Strumenti (ad es.eclipse) contrassegna un avviso per l'uso di metodi deprecati (sebbene sia possibile contrassegnare tali avvisi per essere ignorati). –

+0

Non sto sostenendo l'uso di questa tattica - chiaramente qui c'è un problema più grande e gli effetti della marcatura di qualcosa @decrecated possono essere estremamente indesiderabili, ma soddisfano le esigenze dell'OP. Il thread che ho linkato sui forum di Java suggerisce esattamente come si fa che il metodo dovrebbe essere chiaramente commentato per evitare confusione. –

6

L'unico motivo per cui potrei pensare che vorresti farlo sarebbe quello di "nascondere" il metodo in un certo senso, se non altro in termini di documentazione. Se lo facessi, dovresti progettare la documentazione come "interrotta" nel senso che la documentazione si rompe quando diventa obsoleta e non riflette più accuratamente ciò che fa la classe. Poiché il metodo fa ancora parte dell'API pubblica, non lo stai nascondendo comunque.

Se si desidera che un metodo non venga utilizzato al di fuori della classe o di alcuni utenti, renderlo privato o pacchetto. Se ciò è inopportuno e deve essere pubblico, documenterei molto chiaramente le limitazioni sul suo utilizzo, possibilmente con una convenzione di denominazione (ad esempio, python lo fa, ci sono nomi di entità circondati da underscore, che puoi vedere ma sono pensato per essere più parte dell'implementazione di classe rispetto alla API pubblica)

2
/** 
* Don't use this method <br> 
* <i>or all your data will be lost.</i> 
*/ 
public void foo(){ 
    //... 
} 

bene, utilizzare una spiegazione migliore perché l'utente non deve utilizzare questo metodo ...
Ricordate che non è difficile trovare il metodo qualsiasi (pubblico) utilizzando un decompilatore o di riflessione.