I'm hearing conflicting opinions such as:
- "Dedicated Manager classes are almost never the right engineering tool"
- "Dedicated Manager classes are (currently) the best way to survive a large project with thousands of resources"
Let's take a classic ResourceManager class that has the following functionality:
- Loads assets (textures, audio, 3D models, etc)
- Ensures assets are only loaded once by keeping a cache
- Reference counts assets to determine if they can be deallocated
- Hides where the actual assets came from (e.g., could be one file per asset, or all assets in one package file, or assets could even be loaded over the network)
- Can reload assets without restarting the program, which is extremely useful for the artists working on the game.
Let's also take the "singletons are bad" argument off the table by pretending these ResourceManager objects are not singletons, and instead are passed around via dependency injection.
Then there is the "use a factory" or "call it a factory" argument. My problem with this is that, yes, it is a factory, but it's also a cache and a reloader (for lack of a better word). Calling it a factory doesn't describe it properly, and if I make it a proper factory then where does the caching and reloading get implemented?
I agree that "Manager" classes are often a symptom of bad architecture, but in this particular case how could it be restructured and still retain all of the functionality? Is this a situation where a "Manager" class is actually appropriate?