It has been mentioned in the "Application Framework" section of the LibGDX online wiki that accessing the 6 modules (application, audio, files, graphics, input & net) in a static way is not the best practice.

The exact wording written int the wiki is below:

The modules described earlier can be accessed via static fields of the Gdx class. This is essentially a set of global variables that allows easy access to any module of libgdx. While generally viewed as very bad coding practice, we decided on using this mechanism to ease the pain usually associated with passing around references to things that are used often in all kinds of places within the code base.

But almost all LibGDX applications that I have seen, modules information is fetched in a static way. If static way is not the right way then how to access these modules?

  • 1
    \$\begingroup\$ As it says in the quote "usually associated with passing around references to things" says that these modules would usually be passed from object to object either by adding to the constructor of the object or passing them in a method later. \$\endgroup\$
    – dfour
    Nov 6 '17 at 11:57

My reading of the passage you quoted is that it's not telling you, as a user, "Don't use these static fields we gave you. That would be bad coding practice on your part" (Well then why did the creators expose them? Meanies!)

Rather, it's saying "As a general rule, exposing these static fields is bad coding practice on our part, but we consider it to be a worthwhile trade-off to make it easier for you"

So, there's no particular prohibition on using these modules via their static fields. Since they were designed to be accessed that way, and the creators were apparently conscious of the ramifications of this choice, you're unlikely to create trouble for yourself by going with the flow they created. (And in any case, you can't stuff that genie back in the bottle - they remain globally accessible, with all that comes with that, even if you try to maintain your own more controlled method of accessing them)

In your own code, creating your own new global variables this way can open the door to bugs. Once something is global, it's hard to track down where any particular change to it came from, and it's easy for unrelated parts of your code (or libraries you're using) to do contradictory things with it, unknowingly interfering with each other.

It can also make the code hard to scale: if in the future you need multiple instances of something you used to access via a global variable, or multiple flavours of it, now you need to refactor a lot of code to select the right one.

For these reasons, a number of other patterns are often recommended for handling these kinds of dependencies, such as dependency injection or service locators.

But again, you don't have to worry about that for the built-in modules that are already exposed via static fields. The creators of those modules already weighed these alternatives and decided global access was safe enough and worthwhile for this case, and as you noted, a lot of software uses them this way without issues.

  • \$\begingroup\$ Makes perfect sense. Thank you for the clarification! \$\endgroup\$
    – Harry_S
    Nov 8 '17 at 10:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .