Hodgman, what about something as heightmaps? Let's say I have HeightmapManager, which handles loading Heighmap when it becomes visible, unloading when it wasn't visible for awhile, rendering them, etc?
I think the point most people are making is that the word "manager" itself is ambiguous and there is almost always a better name that can be used to describe the operation.
I don't think it is ambiguous, more so abused. Also, they really shouldn't be as vilified as they are, there is absolutely nothing wrong with naming your class a manager, a lot of the backlash is simply a game of groupthink pile on. The actual flaw, from a design perspective, is creating an everything and the kitchen sink classes that you can call a ____Manager.
If you want to name your class SomethingManager, and it makes sense, call your class SomethingManager. It isn't going to make your code worse or better, nor will it really alter the readability or maintainability. However, clearly define the functionality of your class and keep it as concise as possible.
If for example you have a class for creating, deleting and returning screens, it makes no sense to name it ScreenLoader or ScreenFactory, as it does more than that, and it really doesn't make sense to break these three activities out into separate classes. In this case if you wanted to name your class ScreenManager, and that name makes sense to you... do it! However, if you find your class adding more and more functionality, like displaying, or updating screens, your class design is bad and you are falling into the Manager kitchen sink trap.
In the end, you are the number one person who needs to understand your code, triply so if you are working solo, so if it makes sense for you to name your class a manager, name it a bloody manager.
Managers are a lot like singletons in a way; a new beginner abuses the hell out of them because they are a shortcut (instead of ) good design and eventually they get into trouble when their code reaches a certain complexity... frankly the validity of a design really isn't tested until a certain amount of complexity is reached. As a result there is a giant backlash that USING XXX IS BAD! Reality is, no they aren't bad, neither of them are, but both are ripe for abuse. If you have a global available object that should have deferred allocation, a singleton is the data structure to use. If you have a class that exclusively manages Y, it is a YManager.