How many classes do you come across named 'SomethingManager'? Any decent sized commercial system seems to have plenty - SessionManager, ConnectionManager, PolicyManager, QueueManager, UrlManager, ConfigurationManager, or even, sadly, EJBManager.

A quick look at the dictionary entry for "manager" and "manage" gives at least ten different meanings - from "to make and keep compliant" through to "to achieve one's purpose". I remember one day when the receptionist briefly retitled herself as Switchboard Manager. The common semantic to all these definitions seem to be a vague "looks after stuff".

This imprecision makes Manager a bad word to use in naming classes. For instance, take a class named "UrlManager" - you cannot tell whether it pool URLs, manipulates URLs or audits the use of them. All the name tells you is that this is not a URL, but it does somehow work with them. On the other hand, the name "UrlBuilder" gives a much better picture of what the class does.

In the Java world, it seems that the "Manager" suffix is thrown around a lot. Almost anywhere you have a class that is responsible in any way for other objects, it automatically gets the Manager label.

"Manager" has come to be a danger signal to me - warning of lack of thought on behalf of the application's designer. It either means (a) that the designer couldn't be bothered thinking of a truly descriptive name, and begs the question, "What else couldn't the designer be bothered with?", or (b) that the designer hadn't carefully thought through the role and responsiblities of this class.[1]

"Manager" can therefore be placed on the list of Words Never To Be Used When Naming Classes. That list in full now reads:

"Manager" (suffix),

"Object" (suffix),

"The" (prefix),

"A" or "An" (prefix), and

profanity (anywhere). [2]

Since I've just banned "Manager", it behooves me to suggest some better alternatives:

Herder

A "Herder" looks after things that are too stupid to look after themselves. Taking the insurance domain as an example, let's say you have a whole bunch of Policy domain objects which your application constructs from multiple datasources. You might have a PolicyHerder to find, store and delete policies across various data sources, to ensure that each Policy is only accessed by one agent at a time and to audit all changes to Policies.

"Shepherd" or "Wrangler" could be used if you'd like to avoid the association with cows.

Bucket

A Bucket is a place to stick stuff when you don't need to hold it.

A situation where you need a bucket is for pooling connections to some external resource. When you want a connection, you take one out of the ConnectionBucket, and when you are finished, you put it back.

"Pool" has a more computer-sciency feel to it, but means the same thing.

Supervisor

A "Supervisor" implies allocating work or checking its progress.

In a sytem handling workflow for users, an object responsible for balancing units of work amongst user queues could properly be called a QueueSupervisor.

And More!

There are plenty of other words to use to describe objects that interact with, coordinate are are responsible for others: Auditor, Gatekeeper, Coordinator, Planner, Home, Utility, Builder all come to mind. The trick is to be succinct and accurate.

So, next time you feel tempted to name a class "XyzManager", pause for a few moments, grab the thesaurus and find exactly the right words for a helpfully descriptive name. You will be making the world a kinder, gentler, more understandable place.

[1]I don't count myself innocent of this particular coding sin.

[2]This is a good list. It suggests that the "TheBloodyManagerObject" is a bad name for a class, and it is right.