Come deprecare correttamente i metodi in Java?

5

Oggi ho perso un metodo che stavo usando da quando il mio collega l'ha ridefinito per prendere la sua superclasse. Quindi, dopo la sincronizzazione con il repository ho avuto problemi. Sarebbe stato meglio in questo caso utilizzare alcune annotazioni come @Deprecated invece di rimuovere il metodo in modo da ottenere un messaggio di errore che diceva che il metodo era deprecato? Un sistema di controllo versione o un IDE possono aggirare situazioni come questa deprecando i metodi invece di eliminarli?

    
posta Niklas Rosencrantz 15.11.2013 - 21:21
fonte

3 risposte

11

@Deprecated annotation è la cosa giusta da fare. La rimozione del codice crea interruzioni delle modifiche nell'API che si sta utilizzando: può essere negativo.

Il fatto è che spesso la gente ignora la cosa "cattiva" e usa ancora metodi deprecati perché non fallisce la build. Quindi, la prossima cosa corretta da fare è fare in modo che l'uso di metodi deprecati fallisca la build.

È possibile rendere gli script di compilazione spesso usati dagli sviluppatori Java per fallire la compilazione degli avvisi del compilatore (non solo errori). Ci sono vari approcci per fare ciò a seconda del sistema di costruzione usato (gradle, maven, ant, ...).

Al punto che ora fallisci la build quando (inconsapevolmente) usando il metodo deprecato (hai aggiornato la libreria, qualcosa è ora deprecato, la compilazione fallisce - questa è una cosa buona ).

A quel punto, puoi disabilitare specificamente l'avviso deprecato per quella chiamata di metodo con @SuppressWarnings( "deprecation" ) e poi lo ricostruirà. Ma ora sai che devi correggere quel codice, perché la tua build ha avuto esito negativo e ti ha avvisato della modifica dell'API.

    
risposta data 15.11.2013 - 23:20
fonte
2

Per Java, non sono sicuro delle specifiche della deprecazione oltre l'annotazione @Deprecated . Per rispondere alla tua domanda, non sono a conoscenza del fatto che Git sia almeno in grado di deprecare adeguatamente e chiaramente i metodi stessi (forse non sono entrato in contatto con loro). Secondo la mia esperienza, la rimozione all'ingrosso dei metodi può essere una cattiva idea, come voi stessi siete abituati a usarli; Annotare una classe come @Deprecated può aiutare nel periodo di transizione alla nuova build, in modo che tutti i membri del team possano vedere chiaramente dove quel metodo è andato e perché. Commentando l'annotazione su quando, perché e come il metodo è stato deprecato può essere una buona idea.

    
risposta data 15.11.2013 - 22:42
fonte
2

La deprecazione non è progettata per un singolo progetto in un ambiente di squadra; è progettato per le API pubblicate . All'interno di un singolo progetto, può essere utile come mostrato nella risposta della Mothermole1 per indicare che esiste un modo migliore di usare quella API ora. Questa domanda ha alcuni suggerimenti su come documentare correttamente perché il metodo / classe è stato deprecato e cosa dovrebbe essere usato come alternativa.

Sarei interessato a saperne di più sulle circostanze in cui il metodo incriminato è stato rimosso. Nella mia mente il periodo di tempo in cui il codice è stato utilizzato e il modo in cui è fondamentale per l'app determina la quantità di cerimonie da applicare alla sua rimozione. Se è usato in un altro posto ed è abbastanza nuovo, non mi aspetto alcun processo per la sua rimozione. Tuttavia, se è in circolazione da anni e fa parte di una classe principale che viene utilizzata in tutta l'app, mi aspetterei qualche discussione su come gestire al meglio la transizione.

Ci sono un paio di modi per farlo. Se il metodo in questione è parte di un'API pubblica che viene esportata all'esterno dell'app, il modo migliore è di solito deprecare il metodo in una versione e quindi rimuoverlo nella successiva. Spesso per compatibilità con le versioni precedenti non si può mai rimuovere il metodo; vorresti solo chiarire che non è più supportato. In un'API interna, a seconda di quanto sia pervasivo l'uso e quanto sia complesso da cambiare, lo rimuoverò e correggerò tutti i chiamanti. Nei casi in cui la chiamata viene utilizzata in molti posti ed è difficile cambiare la deprecazione è probabilmente una scommessa più sicura, assicurati solo di riconoscere il debito tecnico che potresti aggiungere al progetto poiché avrai due modi diversi di fare le cose. Puoi prendere in considerazione una strategia di migrazione in cui dovrai eseguire la transizione del codice per un periodo di tempo più lungo.

    
risposta data 15.11.2013 - 23:23
fonte