A type with "Manager" in the name - candidate for refactoring?

I found a thesis on forums:

If you have a type with "Manager" in the name, it's a candidate for refactoring.

On开发者_JAVA技巧e answer:

I know it's considered a code "smell"

So... Why? Is this thesis correct?

There are many managers out there. For example, Ogre3d uses them a lot, and this engine really has a clean architecture.

Ogre3d uses them a lot, and this engine really has a clean architecture.

It does everywhere except the "manager" classes. Look at DefaultSceneManager as an example. These are incredibly huge, nightmarish classes to "manage."

The problem is that most classes with a name including "Manager" typically violate the Single Responsibility Principle. This isn't always true - as a class may have the single responsibility of managing one other aspect, but typically, those will be named differently. When a class gets the name "Manager", it's typically because it's the class overseeing everything - and really should be broken into distinct pieces based on their individual responsibilities.

A Manager when doing lot of things is a smell. If we carefully look into the Manager on what it is doing then you may find lot the things a service does. Splitting, separating them and extract into different a Services makes sense.

You can also find some SRP classes having named suffixed with Manager like 'ConnectionPoolManager'. This makes sense if it does what it says.