I’ve been programming a software version of a board game. Thus far I have written the classes which will correspond to physical objects on the game board. I’m well into writing the program logic, however I’ve found that many of the logic classes require access to the same objects.
At first I was passing the appropriate objects to methods as they were called, but this was getting very tedious, particularly when the methods required many objects to perform their tasks. To solve this, I created a class which initialises and stores all the objects I need. This allows me to access an object from any class by calling Assets.dice(), for example.
But now that I’ve thought about it, this doesn’t seem right. This is why I’m here, I fear that I’ve created some sort of god class. Is this fear unfounded, or have I created a recipe for disaster?
You’ve basically bumped into the singleton pattern. For the most part, it’s a bad pattern. By allowing any part of your app to access essentially global data like this at just about any time, you end up with a spaghetti mess of code that’s hard to maintain, debug, and most of all, test.
I think it is better to create a “Context”, that contains the current dice, pieces, etc etc, and pass the context around as needed to methods/classes that need to use it. This is much cleaner, although yes it is a pain to have to pass it everywhere. But you gain the advantage that you can keep track of who is accessing the Context when, and also you can create mock Contexts for testing purposes. If you pass the context into a high level object, and it must pass it down to its sub components, you know from start to finish what the context is and where it came from.
Also, ideally, it’s nice to make the Context immutable. That may not be possible. But if for each given turn if you can create a new Context that captures the current state and is immutable, you reduce even more surprise from your app.