I found a thesis on forums:
If you have a type with "Manager" in the name, it's a candidate for refactoring.
One 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 Manger 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.