In un programma Java che non ho creato e non posso cambiare, scrivo solo estensioni per esso, il design mi costringe a creare un oggetto che non sarà mai raccolto. Ho testato e posso farlo attraverso l'uso di statica o istanza di oggetti anonimi. So che posso fare qualcosa come:
public static MyObject eternalObject = new MyObject();
e averlo a disposizione ogni volta che voglio su altre parti del programma. Ma posso anche fare qualcosa del tipo:
methodOfBadDesignedProgramWhichIDidNotCreate(new MyObject());
e il programma avrà l'oggetto disponibile per usarlo.
Ho analizzato il dump dell'heap e, in entrambi i casi, l'oggetto non ottiene mai la garbage collection e vive fino alla fine del programma. Il programma ha un design terribile in quanto ti costringe a utilizzare un sacco di statistiche per la creazione di estensioni. Senza contare che la maggior parte dei suoi metodi sono statici e ha oltre 2000 variabili statiche.
Ho cercato di attenuare le perdite di memoria su di esso e mi chiedevo se un utilizzo ha qualche vantaggio rispetto a un altro. Si noti che contrariamente alla credenza popolare, in questo caso specifico, l'istanza dell'oggetto anonima non muore alla fine dell'esecuzione del metodo perché il programma è progettato in modo così grave che il riferimento non viene mai perso. Anche quando l'oggetto non è in uso.
Quindi per un oggetto che non è mai stato raccolto dalla progettazione, l'istanza di oggetti anonimi offre vantaggi rispetto alla creazione di oggetti statici?
P.S. Capirei se questa domanda venga chiusa per essere troppo localizzata in quanto è ovvio che questo è un pessimo progetto di programmazione che solo una piccola parte della popolazione dovrebbe affrontare, quindi non si preoccuperebbero di questo, ma devo affrontare questo problema design perché il mio capo mi obbliga a farlo e non mi consente di creare un nuovo programma da zero, ma solo di creare estensioni per esso. Sto solo cercando di attenuare le perdite di memoria e di fare la migliore programmazione di qualità possibile sul posto di lavoro. Pertanto, chiedo. Comprendere se un uso ha vantaggi rispetto a un altro e lasciare educato o convinto che non ci sia nulla che io possa fare riguardo a questo cattivo software progettato per il quale non posso modificare il codice o crearne uno nuovo.