What we should use instead of a "manager" class in a good OOP design?

Question

I'm having trouble designing my game engine. For example:

When I think in Resources, I think in a ResourceManager class to manage resources on my engine.

This class gets several responsibilities:

• Load resources.
• Map resources by an identifier.
• Ensure that resources are loaded only once.
• Free unused resources (using smartpointers).

This works for me, but I have read on every OOP design tutorial that managers are ambiguous classes with high coupling and low cohesion. I understand this, and I agree, but I searched almost the whole Internet to find a clear example of a real alternative to Managers but I didn't found it.

Some people explain, for example that a ResourceManager should be divided into smaller classes: A ResourceFactory, a ResourceCollection, a ResourceCache, a ResourceFacade...

I know all this design patterns (Factory, Collection, Facade, etc.) But I don't actually understand how this can be joined to create a (easy to manage) resource management system.

My question is: Is there some tutorial or document with a clear example? Can someone explain an example of this system? I'll thank you if you can write a small example in C++ or another similar language.

Thanks in advance for your help!

Answer 1

You almost said it already:

This class gets several responsibilities

(original emphasis).

This violates the Single Responsibility Principle. Additionally, the word Manager suggest an object that manages other objects, which is at odds with the object-oriented principle that objects should encapsulate both data and behavior. This quickly leads to the Feature Envy code smell.

Dividing the manager into many smaller classes is the correct thing to do. To keep them manageable, you can implement a Facade over them.