Perché alcuni elementi di codice (classi, metodi ecc.) nelle API pubbliche vengono deprecati nel tempo?

La solita ragione per deprecare una classe o un metodo è perché è difficile da usare o ha un comportamento che non è più considerato "buono", non perché è stato sostituito con un'implementazione più efficiente.

Ad esempio, la classe java.util.Date ha un costruttore che accetta tre valori interi, per anno, mese e giorno. In superficie, questo sembra un costruttore semplice e ragionevole. Tuttavia, crea un oggetto Date che rappresenta la mezzanotte ora locale per quell'anno / mese / giorno. Quindi, supponendo un'applicazione che viene eseguita in più posizioni, puoi entrare in una situazione in cui hai chiamato questo costruttore con gli stessi valori, ma ottieni risultati diversi. Il che è particolarmente grave se poi memorizzi quella data in un database accessibile in tutto il mondo.

Classi / metodi deprecati raramente vengono rimossi - che il% constructore di% co_de, ad esempio, è stato deprecato fin da quando Java è stato rilasciato pubblicamente, eppure è ancora qui 15 anni dopo. Il motivo è la retrocompatibilità: non si vuole rompere il codice esistente, anche se il codice dovrebbe essere riscritto. Ad un certo punto, tuttavia, la rottura della compatibilità potrebbe essere una scelta migliore rispetto al trasporto di molti metodi deprecati.

Penso che la tua prima ipotesi abbia praticamente capito. Supponendo s / ammortizzato / deprecato / comunque.

In generale, le funzioni sono deprecate quando esiste un modo migliore per realizzare ciò per cui sono state originariamente utilizzate. Questo accade in tutte le lingue e in molti progetti e può essere applicato sia alla sintassi che alle funzioni e ai metodi.

It is because the Java API developers may find those classes or methods are using an algorithm which is not efficient and they replace them with another class(es) or method(s) which are more efficent.

Questa potrebbe essere una delle ragioni. Un altro è che potrebbero rendersi conto che qualche metodo / classe è difettoso, soggetto a errori, difficile / non intuitivo da usare o chiaramente rotto.

La progettazione di API è difficile. Spesso i progettisti sono sotto la pressione del tempo, in un nuovo campo, quindi prendono decisioni le cui implicazioni non sono completamente comprese in quel momento. A volte risulta che una tale decisione ha conseguenze negative inaspettate. Quindi un modo migliore è concepito nella prossima versione API / framework / lingua, e il vecchio potrebbe essere deprecato.

La deprecazione consente ai manutentori Java di eliminare un'API errata dando agli utenti il tempo di migrare. Mantenendo le API vecchie e nuove, è possibile aggiornare la JVM con modifiche minime in un solo passaggio e correggere l'API deprecata in un secondo progetto. Funziona anche come avvertimento per gli sviluppatori che una particolare funzione è compatibile con il vecchio codice non modificabile e non dovrebbe essere utilizzata.

Per quanto riguarda il motivo, se fosse solo l'algoritmo a essere cattivo, è possibile correggerlo nella libreria senza modificare l'API. La deprecazione è per quei tempi in cui l'API stessa era progettata male. Ad esempio, considera strlen vs strnlen in C. Oppure la vecchia API si basava su ipotesi sull'implementazione interna di Java stessa.

Perché gli sviluppatori di quelle classi, librerie e framework sono anche umani. Fanno errori, imparano facendo e migliorano le cose nel tempo. Ciò significa che non ottengono alcune cose fin dall'inizio e devono recuperare le versioni future.

Un'altra parte della storia è che spesso richiede un'esperienza pratica con uno strumento e un ampio feedback da una vasta comunità di utenti per comprendere il profilo di utilizzo dello strumento, i suoi lati deboli e forti, il suo più popolare e meno funzioni popolari, parti di esso che confondono gli utenti e fanno sì che abusino di determinate funzioni e producano bug. Solo sulla base di tali informazioni diventa possibile ottimizzare lo strumento e adattarlo alle reali esigenze dell'utente.

A volte le cose vengono deprecate perché risultano non sicure o perché l'implementazione sta causando problemi altrove. Ad esempio, la funzione di libreria C standard gets è il poster child per gli exploit malware, a causa della sua incapacità di proteggere dall'overflow del buffer. È stato deprecato nello standard C99 e sembra completamente scomparso dallo standard C1X proposto. Il caos che una piccola libreria ha attivato è più spaventoso della prospettiva di infrangere più di 35 anni di codice legacy.

La risposta che potresti cercare è che le API non possano essere cambiate. Una volta rilasciata una API, è lì. La sua modifica spezzerebbe il codice esistente affidandosi ad esso.

Quindi, anziché modificare un'API, gli sviluppatori lo contrassegnano come deprecato e creano una nuova classe / metodo.

In questo modo il vecchio codice continua a funzionare mentre d'altra parte i metodi migliori diventano disponibili per il codice che scrivi ora o in futuro.

Penso che questo sia ciò a cui il tuo professore suggerisce: deprecare e creare nuovi metodi invece di cambiare.