Kill All Your Managers

Not your line manager, obviously. I mean your Manager classes.

I've been having a debate today with a colleague who was looking for a suitable name for a new class he was about to write.

The initial guess he came up with was the FooBarManager. When I asked him to describe the responsibility of this class, the answer was kind of vague, it would do a bit of this, a bit of that, a bit of everything really.

Which made me think.

Naming a class with the Manager suffix may seem reasonable at the time but it implies such a vague responsibility definition that it is almost certainly a code smell. It usually means that you are assigning too much responsibility to it.

Not only is this bad for it's own sake, for maintainability and separation of concerns, the next programmer to touch the code (which may be you in six months time) may use the vague responsibility boundary as an excuse to shoehorn in unrelated code rather than creating something with more well defined responsibilities.

That way lies a lifetime of cruft accumulation and code archaeology for your future self and your colleagues. Please don't do it.

The c2 wiki has a good discussion on the subject: Dont Name Classes Object Manager Handler or Data and the Taligent Object Oriented design guidelines has an article Managers are not objects

On the other hand, if think FooBarManager is a good name, you might just like two websites Class Namer by Aaron Beckerman and Method Namer by Jeff Foster @fffej on Twitter