Making classes available to others

Question

I'm currently working on a 2D game engine in XNA, and I am very interested in architecture, and how best to let my game objects communicate.

I know a lot of people use a Singleton design but I believe that this is more of a "counter-architecture" way of doing things, as every class will have access to the Singleton.

I was comtemplating using a Service-type architecture to allow for my Input, Sound, etc Manager classes to be available, but this is essentially the same problem as the Singleton as all the Classes are available to 'whoever' wants them.

I could of course pass references to the objects when they are needed, but this is bloated.

I wonder if making the 'Services' only allow certain objects to subscribe would be possible?

So is there a better way to make your classes available?

Or am I searching for an answer that doesn't have a question?

Answer 1

When you're writing a game, you're better off writing a game than worrying too much about having the perfect architecture. There's nothing really wrong with having singletons and global variables in a game. Far better to have less and more flexible code than for it to be perfect.

I personally find that Singleton is a pattern to be avoided. Most of the time you should be using a static class or member instead of a singleton. See, for example, the Mouse and Keyboard and MediaPlayer classes in XNA. These are all simply static classes which are globally accessible.

I would query your need for a "sound manager", seeing as SoundEffects are stand-alone. And ContentManager is already the only thing you need to "manage" them.

You don't really need to write a services architecture, because XNA already provides one (see Game.Services).

If it seems like it would help, there's no reason why you can't just add a public static MyGame theGame member to your Game class and effectively turn it into a singleton. For the simple reason that there is never reasonably going to be more than one instance of your game class. Then you can make its members public (Content and Services already are) and access them globally, if it makes sense. This is simple. You can always change it to something more complicated later!

Making only your Game class a globally accessible also keeps the global access point localised to one place in the code, making it easier to locate when you want to "un-globalify" something later.

What I would very much avoid is making true Singleton classes that can only be instanced once. For example: don't make a map class that you can only create one instance of: what if you want to add background loading of the next map later? (Or the player class - for multiplayer, and so on).

The best example of this "global but not singleton" in XNA is ContentManager. You've got Game.Content which is effectively global. But you can also create more instances of ContentManager, which can be owned by whatever you like (levels, screens, whatever) and will operate independently.

Answer 2

I could of course pass references to the objects when they are needed, but this is bloated.

No, that's completely how it should be done. If you find doing this untenable, then your design is broken.

Passing references makes for the easiest, most obvious control and encapsulation. Global data is bad, whether you want to call it a "Singleton" or a static Manager. You shouldn't even need an InputManager or a SoundManager.

Answer 3

The major difference between the singleton approach and the service locator approach is that the components are more loosely coupled. If Foo accesses Bar as a singleton, any changes to Bar affect Foo indirectly.

With a service locator you can communicate through an interface though, IBar say. You can change Bar all you want as long as it fulfills the IBar contract. If you decide that the class Baz should now fulfill the IBar contract, you can just swap it out. With the singleton, you can't do that so easily.

Answer 4

My advice is that a good programmer isn't dogmatic. Passing things by reference is good, singletons are also good. A good programmer uses every weapon in his arsenal, they don't rely on using a single tool, a hammer can't solve every problem.

For instance I would say it is a bad design to be passing around the same reference to a single object everywhere.

Singletons aren't counter-architecture, they're part of the GOF patterns and it is an extremely useful pattern. As all architecture, they have a proper time and place, architecture for its own sake is a common mistake. A singleton is appropriate when there should only ever be one instance of that class in your application and that instance is referenced everywhere.

You want to restrict access to singletons? A good design is not just about classes, its also about appropriate packaging. By using the internal C# access modifier you can limit use of a singleton to within a particular package/assembly.

Answer 5

This is a problem throughout all of software development, and there are several common solutions.

Fortunately, you don't really need to pick one - XNA already has a built-in service locator!

Answer 6

I think you can use mutiple inhertence for your need and have some game object like these :

class KeyboardReader
{
    protected :
    static KeyBoard* keyboard;
};

class MouseReader
{
    protected:
    static Mouse* mouse;
}

class gamecontroller:public KeyboardReader, public MouseReader
{

}