Quale processo / linee guida dovrebbero essere seguite, quando sto per deprecare alcuni metodi dalle mie classi di servizio in Java?

Idealmente non penso che tu voglia sabotare i metodi esistenti. Comprendi a cosa serve la deprecazione:

You have methods you no longer wish to maintain for whatever reasons--better alternatives, security problem, etc. Problem is you have existing users that need time to migrate to the new API. Deprecation is the process of notifying your users that there is a new API and the old one will no longer be supported.

Quando disattivi una funzione per la prima volta, farai incazzare un gruppo di utenti se lo disabiliti completamente. I loro utenti inizieranno a lamentarsi di come l'app si sia improvvisamente spezzata e tutto ciò che hanno fatto è stato aggiornare la libreria per le nuove funzionalità. (Gli utenti non pensano sempre queste cose attraverso). Quindi segui questo processo:

• Nella prima versione deprecare un metodo, contrassegnarlo come deprecato con le annotazioni e il documento in Javadocs, cosa invece dovrebbero essere le persone. Aiuta anche a documentare perché è stato deprecato, in particolare se si tratta di un problema di sicurezza. Specificare inoltre che il metodo / funzione non sarà più mantenuto dopo questo rilascio. Ciò dà alle persone il tempo di migrare.
• Se il metodo è particolarmente problematico (come Java Thread.stop() ) o un problema di sicurezza principale, disabilitarlo nella prossima versione dopo la deprecazione. Per disabilitazione intendo gettare un'eccezione. Se è Java lancia qualcosa che estende Error perché è pericoloso da usare.
• Se il metodo non è problematico, mantienilo per un'altra versione o due, ma mantienilo a sufficienza da compilare. Non mettere più sforzi in questo. Ricorda, non prometti di mantenere la funzione più.
• Infine, quando hai avuto un paio di versioni con la funzione contrassegnata come deprecata, puoi rimuoverla completamente. Tutti dovrebbero avere avuto abbastanza tempo per migrare (almeno dare loro sei mesi, dato che alcuni progetti sono più lenti da aggiornare rispetto ad altri).

A parte l'annotazione "@Deprecated", aggiungerei a javadoc perché è deprecata, le alternative da usare e definisco un periodo per mantenerla in quel modo. Dopo questo periodo, modifica il metodo per generare un'eccezione con un messaggio che dice che il metodo "B" è stato deprecato e non funziona più.

Rimuovere semplicemente i metodi o aggiungere quell'eccezione non è una buona idea perché molti programmi inizieranno a fallire, di solito li segnaliamo come deprecati e semplicemente non eseguo aggiornamenti o correzioni di bug su di essi. Deprecato è proprio questo, "il metodo non verrà più aggiornato"

Gli altri progetti inizieranno a ricevere avvertimenti sull'utilizzo di un metodo deprecato, quindi prima o poi le cose verranno corrette.

Penso che non ci sia una regola generale applicabile a tutti gli scenari qui.

Dipende molto da chi sono gli utenti della biblioteca. Più piccola è la base di utenti e più la base di utenti è vicina a te e al tuo team e maggiore è la possibilità che tu possa influenzare le applicazioni utilizzando la tua libreria, più "aggressivo" puoi cambiare la tua API pubblica.

Quando si modifica il codice cliente è relativamente semplice, si potrebbe documentare in modo esplicito "questo metodo è deprecato nella versione 1.x e verrà rimosso nella versione 1.x+1 . Ovviamente questo funziona solo se i client sono in grado di seguire le modifiche. Se non conosci bene i clienti, potresti essere costretto a mantenere stabile l'API per le future generazioni e devi mantenere i metodi per motivi di compatibilità fino alla versione 1.x+10 .

La chiave qui è comunicazione - quando tutti sanno cosa è successo in un rilascio, possono adattarsi ad esso.