Should I avoid long method chaining simply to get a variable?

Question

I am working on a game, and I have many instances where I have to do something like this:

Game.getInstance().getEnergyDropManager().getDrops()

Or:

this.dimensionSelector.selectDimension(Game.getInstance().getPlayer().getCurrentDimension().getColor())

This gets long to write and not as readable.

I could have a class with a short name that has a bunch of static methods which are shorthand for returning these. But this doesn't "feel right".

I could do as this question suggests, but I really don't like this, and the accepted answer also says this is a bad idea.

Are there any other ways of dealing with this? Should I use method 1, or just keep doing what I'm doing?

EDIT: I could see the question I referenced being marked as a duplicate. It doesn't answer my question, it simply says "don't do that." Also, my method chains are quite a bit longer.

Answer 1

The long chaining is a sign that you're tightly coupling classes which should probably not be tightly coupled. For example, you wrote:

Game.getInstance().getEnergyDropManager().getDrops()

The class which needs drops is being coupled with Game and EnergyDropManager. While it's true you're using a singleton (though if you were following best practice, you perhaps wouldn't), you still must reference both in the calling class.

I obviously don't know the context of the call, but supposing you were rendering a frame, and you must draw all the drops. This class needs a reference to EnergyDropManager, and not Game. The game logic presumably is done in Game and should remain there, unless you have reason to think that your rendering class needs to change the Game logic. However in this case, you should reconsider the purpose of your rendering class, as it does more than simply "draw".

It is fine that Game has a direct link to EnergyDropManager, but don't necessarily assume that Game should be coupled with every other class if it isn't strictly required. Think in terms of context of who is calling and everything it needs. If it needs EnergyDropManager for 99% of calls, and one call to Game, you should reconsider the purpose of that method in that context and whether it might be wiser to move it to EnergyDropManager instead, for instance.

In conclusion, it's the other side of the coin. Using classes is crucial for modularizing your code and not putting everything in a single god class. On the other side of the coin, you must analyze who is calling and whether the context is correct for accessing each called class involved. If it isn't, eliminate all references to that class.