Sulla base delle definizioni che ho letto del termine deprecazione, ho la sensazione generale che la deprecazione sia di solito riservata per passare ad altri metodi / classi per buoni motivi (e prendo in prestito da Wikipedia):
- La funzione è stata sostituita da una più potente funzionalità alternativa.
- La funzione contiene un difetto di progettazione, spesso un difetto di sicurezza, e quindi dovrebbe essere evitato, ma il codice esistente dipende da esso.
- La funzione è considerata estranea e verrà rimossa in futuro per semplificare il sistema nel suo complesso.
- Una versione futura del software comporterà importanti modifiche strutturali, rendendo impossibile (o poco pratico) il supporto di funzionalità meno recenti.
- Standardizzazione o maggiore coerenza nella denominazione.
- Una funzione che una volta era disponibile solo indipendentemente è ora combinata con la sua co-caratteristica.
È appropriato deprecare un metodo / una classe se esiste la possibilità che le future decisioni prese nelle versioni successive del codice possano richiedere il ripristino della funzionalità deprecata? Cioè, è corretto non sottovalutare? Forse se no, qual è il modo corretto per gestire questa sezione di codice?
Nel contesto di cui sto parlando, il deliverable è in realtà un sottosistema che è incluso in altri progetti. Pertanto, la possibile esposizione è tra i team di sviluppo. Tuttavia, alcune delle classi deprecate, per esempio, non sarebbero classi che sarebbero normalmente istanziate direttamente da altri progetti. Potrebbero, ma generalmente non si adatta ai loro casi d'uso. Un esempio che viene in mente è Stanford CoreNLP, dove solo perché una classe o un metodo è accessibile non significa che sia qualcosa che tu dovrebbe usare.