This article is intended for those of you that you love and abuse the “manager” concept. I know you’re there, don’t try to hide yourself :).

The idea of a manager quickly gets into the mind of a developer when he designs a project. Sooner or later, you’ll need a manager that will coordinate some stuff. That’s not entirely wrong, but let’s see what managers are suitable for and what are not suitable for.

1. Managers are intended to coordinate multiple similar objects. The words “multiple” and “similar” are the key terms here. Think as in real life: you can’t have a manager for a single person (though there are exception from this, of course), and you can’t ask the same manager to handle both carpenters and welders at the same time, it  will not probably do a good job for neither of the two categories.

2. Managers can’t be used as the main coordinator of the application – i.e. the entity that knows of all modules and instructs them how to behave. That’s simply not a manager, that’s a fat class. And sooner or later you’ll wish you’d never had it. This kind of classes are simply not maintainable over a period longer than a year.

3. Managers are not singletons. Think as in real life, each person should know it’s manager. Thus, dependency injection. Even if implemented as singleton, the objects managed by the manager should receive a reference to that manager, instead of relying on a global instance.

My recommendation is to think twice before choosing a class name that contains “manager”. Reflect if the class really needs to coordinate a group of objects, and if it can do this without getting too fat and without needing the help of another N objects.