"Manager" classes can be problematic for various reasons. The two key reasons tend to be:
- the name is unclear (what actually does "management" entail, and is it always the same for every type of thing being managed?)
- they tend towards being buckets of functionality that violate the single responsibility principle (that is, that a type should do one thing)
Often one of those reasons causes or implies the other.
Those issues are good things to keep in mind, but don't them let paralyze your ability to actually make your game. In the end nobody is going to care what your classes are called or what they do. They're going to care about your game.
It's usually pretty easy to separate most "managers" into two parts:
the part that stores the actual objects and provides access to them (which you can call a "store," a "repository," a "database," a "cache," or various other things. This is the type that is usually responsible for the lifetime of the objects; that is, when an object is removed from or otherwise no longer contained by an instance of this type it ceases to exist.
the part that processes the actual objects and performs some work on them. It might update those objects (then it's an "updater" or "simulation") or it might draw them (then it's a "drawer" or "renderer"). Or it might do something else with them; the important thing is to name it according to its primary purpose. You'd generally give instances of this type a instance of or reference to instances of the first type (the one that just handles lifetime of the objects).
A reasonable argument could be made that the name of the first type could include manager (as it "manages the lifetime of" some objects). The world will not end if you name your type thusly, although you may need to put up with knee-jerk reactions of the form "don't call things managers" rather often, so you may want to avoid it just for that.