[EDIT] – The key point I was trying to make is to watch out for class names that do not communicate their intention. If SomethingManager has a specific meaning in your system and your team is happy with it, that’s all good. A code smell means something to be concerned about, not automatically something that is wrong and has to be changed.
Jeff Atwood on Coding Horror has a good post up called “I shall call it.. SomethingManager” that’s collecting some good comments as well.
C. Keith Ray also had a related post late last year about “SomethingUtility” classes.
For my part I’d label classes named “SomethingManager” and “SomethingUtility” as a full fledged code smell. I.e., an indication that something *might* be wrong with your code that requires some of your attention.
Ideally all classes have a distinct role and responsibility within the greater system. That role and responsibility should be reflected by the class name. Like Keith says, a “utility” or “manager” class might be indicative of a procedural system where class responsibilities aren’t being adequately understood or modeled. If you can’t think of a better name for a class than “SomethingManager” it’s a sign that you don’t fully understand the scope of its responsibility.
I work with some legacy code that has a lot of catch all utility classes that just lump a lot of broadly related methods together. The result is a handful of very large classes that have too many unrelated responsibilities and a considerable amount of difficulty in locating code.
The analogy I would try to draw is which situation would you rather have, “the gardening shears are on the tool shelf” or “they’re in the garage somewhere?” Figuring out where to put a responsibility in the system in such a way that others could readily find it later is a key exercise in creating maintainable systems.