Object Manager? Design pattern

Question

I have a lot of objects that need to be passed to other objects. It's a game, so the player needs to know about the world and the world needs to know about maps, etc.

Instead of passing all these around, I was thinking of creating one "Master" object manager and then registering these objects with it. I would pass around the master object manager and everything that need something could just do a "masterObject.getPlayer()" or whatever.

Is this a real design pattern? If so, what is it called? Any downside.

Answer 1

This is a frequently used approach, and when handled sensibly can be very useful. While some people dislike them and refer to them as "God classes", they are really not if properly structured. The problems start to come if you think about it just as "the class that holds everything" - but if you think about the information structure you should be OK.

Let's take an example. Let's call the class you are interested in "Game". That's always a good place to start because it represents a real world entity. A Game should know things about itself: player1, player2, map, turnNumber. Put methods on Game to access these. That's perfectly correct and good design. Then these objects will in turn know things about themselves. Player will know name, skill-level, energy-remaining. Map will know size, and the terrain on each square. If you need to know about an individual square then you have the Map class implement getSquare(x,y). The Square knows what its terrain type is.

The key thing is that you only pass to a method the thing(s) that it needs. The method that calculates the path between two units takes Map as its argument. You don't pass it Game and let it extract the Map.

Many systems have objects like this. java.lang.Runtime is an example. However you should minimize their use through the techniques above.

There is one very important temptation to avoid. After you have found that your 'Master' class is being passed to almost every method, you may think "Why don't I just make that class accessible to every method without it being used as an argument?". That way lies Singletons. Avoid.

Answer 2

What you describe is a design patter, er rather, an anti-pattern. It is sometimes known as the God class and should be avoided.

Wikipedia's article explains the basic problem with the God class. Specifically, such an object would violate the Law of Demeter. It basically says don't talk to strangers. All objects retrieved from the God object would be strangers and it is best to avoid sending them messages/calling methods.