Naming Java Classes Without a 'Manager'

5 PM February 25, 2003

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:


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.


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.


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.

By alang | # | Comments (6)
(Posted to Software Development)


At 00:35, 26 Feb 2003 weolopez wrote:

You have hit on one of my biggest if not my biggest pet programming peeve. The suggestion I always make to people that do this is that they rethink their object structure and more likely split the functionality in multiple objects or just dump the suffix and just call the object what it is and make the management functionality method names.

like URLManager just make it URL. Let the objects manage them selves and if you need a class to pool URLs create a URLPool class.

There is nothing more ambiguous than a manager class. Thanks for the blog, every once and a while you find a diamond in the rough.

At 00:49, 26 Feb 2003 Darren Greaves wrote:

Add Util to that list too.

Util is just another word for "can't be arsed to think of a proper name for it".

At 03:07, 16 Jan 2005 rstoya wrote:

I came across this article precisely because I couldn't decide how to name a class. I guess I was tempted but didn't want to call it "Manager". We have too many "managers" as it is. Another name that comes up often as well is "Director".

My difficulty in thinking of a name (and maybe for others as well) was that it's hard to pick one word to describe the alogirithm of the class.

But I think you're correct in suggesting that we should try to generalize and pick one word that is a bit suggestive than manager.

At 18:20, 31 May 2006 Mohinder wrote:

So, ReportManager is no good then? And FieldPropertyManager is also no good? Goddamnit! Me and my rookie ways get me nowhere.

At 05:16, 11 Sep 2006 Mohan wrote:

Very good article.

At 23:19, 29 Nov 2006 Andrew Kirkland wrote:

I've tried so many times with so many developers to explain that you can't just slap Manager on the back of a class. I'm glad there are others that think the same way, as most developers I have this conversation with look at me blankly and then do it anyway.

I also dislike the use of the word Engine on the back of anything. The only time I would feel the need to put Engine on the back of something is if I'm going fishing. I've never understood how Engine adds any value in describing a classification.

Nice article - thanks.


Add Comment

(Not displayed)

(Leave blank line between paragraphs. URLs converted to links. HTML stripped. Indented source code will be formatted with <pre> tags.)

© 2003-2006 Alan Green