Il lungo concatenamento è un segno che stai strettamente abbinando le classi che probabilmente non dovrebbero essere strettamente accoppiate. Ad esempio, hai scritto:
Game.getInstance().getEnergyDropManager().getDrops()
La classe che ha bisogno di abbandono viene accoppiata con Game e EnergyDropManager . Anche se è vero che stai usando un singleton (sebbene tu stia seguendo le migliori pratiche, forse non lo faresti), devi comunque fare riferimento entrambi nella classe chiamante.
Ovviamente non conosco il contesto della chiamata, ma supponendo che tu stia eseguendo il rendering di una cornice, e devi disegnare tutte le gocce. Questa classe richiede un riferimento a EnergyDropManager e non Game . La logica di gioco presumibilmente è fatta in Game e dovrebbe rimanere lì, a meno che tu non abbia motivo di pensare che la tua classe di rendering debba cambiare la logica Game . Tuttavia, in questo caso, dovresti riconsiderare lo scopo della tua classe di rendering, poiché fa più che semplicemente "disegnare".
Va bene che Game abbia un link diretto a EnergyDropManager , ma non necessariamente supponiamo che Game debba essere accoppiato con ogni altra classe se non è strettamente richiesto. Pensa in termini di contesto di chi sta chiamando e di tutto ciò di cui ha bisogno. Se ha bisogno di EnergyDropManager per il 99% delle chiamate e una chiamata a Game , dovresti riconsiderare lo scopo di quel metodo in quel contesto e se potrebbe essere più saggio spostarlo su EnergyDropManager , per esempio.
In conclusione, è l'altro lato della medaglia. Usare le classi è cruciale per modularizzare il codice e non mettere tutto in una singola classe di dio. Sul lato altro della medaglia, devi analizzare chi sta chiamando e se il contesto è corretto per accedere a ogni classe chiamata coinvolta. Se non lo è, elimina tutti i riferimenti a quella classe.