Quando deprecare e quando eliminare in Java

Question

Quando deprecare e quando eliminare in Java

#1 da (16 voti)
#2 da (6 voti)
#3 da (5 voti)

10

Come parte di uno sforzo di refactoring o semplicemente di uno sviluppo in corso, un particolare metodo o forse un'intera classe può diventare obsoleto in un certo senso. Java supporta l'annotazione @Deprecated per indicare che probabilmente esiste un modo migliore per gestire la funzionalità in questione. Immagino che questo sia particolarmente utile nelle API pubbliche in cui gli effetti della rimozione di parti di un'API potrebbero non essere noti. Per un'API non pubblica e un progetto che utilizza i sistemi di controllo di revisione (quindi l'eliminazione può essere annullata in un certo senso), quando è opportuno deprecare piuttosto che eliminare gli elementi obsoleti?

refactoring programming-practices java

posta Michael McGowan 13.04.2011 - 18:00

fonte

3 risposte

Leggi altre domande sui tag refactoring programming-practices java

Come funzionava la programmazione quando i programmatori usavano le punch card? Chi dovrebbe scrivere il piano di test?

score 16 · Answer 1

La tua API è un'API pubblica? Che determina se devi o meno deprecare o rimuovere. Se l'API è strettamente a tuo vantaggio (ad esempio utilizzato solo all'interno della tua azienda), allora è meglio rimuovere semplicemente il codice incriminato. È molto più pulito e causerà meno problemi di manutenzione a lungo termine.

Tuttavia, se l'API è pubblica, la semplice rimozione di un metodo può causare il blocco del codice utilizzato per le versioni precedenti della libreria. Ecco dove le cose si complicano. Le seguenti sono alcune linee guida:

API interna: rimuovi anziché deprecato. Se un client utilizza una classe o un metodo interno, è colpa sua se lo strumento si rompe.
API esterna: prima deprecare, rimuovere in seguito. La deprecazione è una bandiera che qualcosa verrà rimosso in seguito. Più tardi dipende da ciò che credi sia ragionevole. Per lo meno fornisci 2-3 versioni prima di rimuovere effettivamente il codice deprecato.

score 6 · Answer 2

Probabilmente è una buona idea impostare un promemoria quando @deprecate una classe o un metodo. Lo stai facendo per promuovere la sua obsolescenza. Quindi, immagina quanto tempo ci vorrà, come tempo libero, come-ti-ottieni-per-compito, per eliminare tutti i riferimenti. Contrassegnalo come @deprecated e metti un promemoria nel tuo calendario. Quando ricevi il promemoria, controlla. Se non è più utilizzato, eliminalo. Se rimangono un paio di riferimenti che possono essere rapidamente aggiornati, farlo ed eliminare l'elemento. Se il lavoro più significativo rimane, rispondi un po 'il tuo promemoria.

Fai questo abbastanza volte e svilupperai la sensazione di quanto tempo ci vuole per sbarazzarsi di una classe o di un metodo nei tuoi progetti.

score 5 · Answer 3

IMHO se puoi essere certo che nessuno lo stia usando e non lo farà mai, basta rimuoverlo. (Questo può essere complicato in presenza di riflessioni, o componenti esterni come le macro Velocity - i moderni IDE come IntelliJ possono trovare riferimenti ad esempio in JSP ma non tramite reflection o in Velocity.)

Se esiste un'alternativa migliore ma quella vecchia è ancora utilizzata in molti posti, e al momento non hai il tempo di rifattorizzare tutto il codice client, è sufficiente @deprecare la classe / metodo obsoleto (con un commento adeguato sull'alternativa favorita).