Should game services be global? (XNA)

Question

If one wants to use services, they can use the ones built in to XNA (Game.Services) and pass around the Game object to everything that needs to either query for a service or add a service.

Alternatively, one can create their own game services class and make it static to avoid having to pass around Game everywhere.

Instead of just passing Game to everything, just to query the services (a code smell already in my opinion, just pass the services) seems a bit silly to me. Instead of passing it everywhere, why not just make a public static GameServices class?

What are the advantages and disadvantages of each approach? Which do you normally opt for?

Answer 1

First of all: DTSTTCPW. You probably shouldn't be using services at all. If you can send around individual objects, you should generally do that. I recommend you read my description of why services exist, on Stack Overflow.

Otherwise, if you specifically want to use services for your architecture:

The architecturally correct thing to do would be to take an IServiceProvider object as an argument (to which you you could pass Game.Services) for any object/method that needs to consume services. This is what ContentManager does.

For an object/method needs to add services, you should pass around Game (this is what XNA's GraphicsDeviceManager's constructor takes, so it can add the IGraphicsDeviceService) or GameServiceContainer (which is what Game.Services is).

(It should be noted that the whole Game assembly is optional in XNA - there is no way to make an object that can add services without introducing a dependency on that assembly. IServiceProvider is part of the .NET framework - but it cannot be used to add services.)

It is "bad" architecture to make these things global. But you can do it for expediency - as long as you understand (and comment appropriately) why you are doing so. Just be mindful that you may need to "undo" this deliberately-bad architecture in the future.

(There are many reasons globals are bad architecture. Here is just one good reference.)

Answer 2

Because it allows a different Game object to be swapped out, without requiring modifying code or recompiling/reloading - the object can be changed during runtime.

This would allow developers to write different Game objects (for an online game) that come preloaded with services for development against a local dev server, and one that contains the final production server references. For example.

Using static classes/methods tie the invocation in the calling code to a specific class/method (it disables polymorphism, of course). Among other things, this makes unit testing extremely difficult. Unless the called function/class is very unlikely to change (like say, a Math library), using Dependency Injection will save a lot of headaches - more so if you're able to wire things at run-time, and through the use of config files.