Object Manager? Design scheme

Question

I have many objects that need to be passed to other objects. This is a game, so the player needs to know about the world, and the world needs to know about maps, etc.

Instead of transferring all this, I was thinking of creating one Master object manager, and then registering these objects with it. I would go around the master object manager and all that needed is something, could just do "masterObject.getPlayer ()" or something else.

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

Answer 1

This is a commonly used approach, and when handled properly, it can be very helpful. While some people do not like them and call them “classes of God,” they are not really properly structured. Problems begin to arise if you think of it in the same way as a “class that contains everything,” but if you think of an information structure, you should be fine.

Take an example. Let me name the class that interests you "Game". It is always a good place to start, because it is an object of the real world. The game should know about itself: player1, player2, map, turnNumber. Put game methods to access them. This is a perfectly correct and good design. Then these objects, in turn, will know about themselves. The player will know the name, skill level, left without energy. The map will know the size and terrain on each square. If you need to know about a single square, then you have an implementation of the map class getSquare (x, y). The square knows what its type of terrain is.

The main thing is that you only pass the method (things) that he needs. A method that calculates the path between two units takes a map as an argument. You do not pass the game and do not allow it to remove the card.

Many systems have such objects. Example java.lang.Runtime. However, you should minimize their use using the methods above.

There is one very important temptation to avoid. Once you find that your Master class is passed to almost every method, you might think, “Why don't I just make this class available to every method without using it as an argument?” So these are singletones. Avoid.

Answer 2

What you are describing is a project template, but rather an anti-template. It is sometimes called the class of God and should be avoided.

The Wikipedia article explains the basic problem with the class of God. In particular, such an object violates the Law of Demeter . Basically he says don't talk to strangers. All objects extracted from the God object will be unfamiliar, and it is better to avoid sending them messages / calling methods.

Answer 3

Another angle on this - compared to the answers of Will O and Jeune - is that this is a good old record; No more no less. Whether this is the right design decision or an example of an anti-God-class pattern depends on the circumstances. I would say that it is normal when this class does not make your code base mutually recursive, and when there is no real code nearby in this class, just the attributes of the instance apply to all other objects.

Answer 4

Try looking at the observer pattern . It resembles the world you are describing. There is a main object (observable), and there are observers who register at the main object. If there is a change in the world, the main object simply notifies the observers.

In addition, I think you can use other methods to suit your needs, but this is essentially a concept.