CODEWITHSUNDEEP
javaoop
user697111
user697111

Reputation: 2262

Object Manager? Design pattern

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.

Upvotes: 7

Views: 11977

Answers (4)

DJClayworth
DJClayworth

Reputation: 26846

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.

Upvotes: 16

jmg
jmg

Reputation: 7404

Another angle on this - compared to the answers of Will O and Jeune - is that this is a good old record; nothing more and nothing less. Whether this is the right design decision or an instance of the 'God class' anti-pattern depends on the circumstances. I'd say it is ok, when this class does not make your whole code base mutually recursive, and when there is next to no actual code in that class, just the instance attributes to refer to all the other objects.

Upvotes: 1

willscripted
willscripted

Reputation: 1456

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.

Upvotes: 3

Jeune
Jeune

Reputation: 3538

Try having a look at the Observer Pattern. It resembles the world you are describing. There is a master object (observable) and there are the observers who register themselves to the master object. If there are changes to the world, the master object just notifies the observers.

Additionally, I guess you can put in other methods to suit your needs but that is essentially the concept.

Upvotes: 0

Related Questions