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)

Interview With a Programmer Too

12 PM February 25, 2003

Charles makes some interesting points about interviewing programmers. Don't forget to check out the comments - Blake Winton has an interviewer's perspective.

I have had cause to interview programmers over the years. It is both interesting and difficult work.

My favourite set of questions for interviewees starts by asking them to describe a large system that they've worked on before - I pick an appropriate one off their resume - and getting them to draw the system on a white board.

The interviewee gets to decide from which point of view to describe the system. If they ask, I tell them to pick whatever they are most comfortable with. They might describe the system from a business point of view (data flows between user departments, reports, and letters to customers) as a technical architect (hardware, IP networks, J2EE), or as a programmer (class and interaction diagrams), or as something else altogether. This is a good time to see how they answer questions from what may not be their natural perspective (What was the business case for this system? How many classes were there altogether? Who wrote the coding standards?)

After a little bit of probing, and getting about 10 boxes on the whiteboard, I then ask what they thought worked well in that design and what worked poorly. I also ask them what they would do if it were up to them to redesign the system from scratch. The intent of the question is to evaluate their design skills, and whether they think critically about what they are doing.

From this, I start making up my mind about whether they are a thinker, a leader, a starter or a finisher, experienced or new or just along for the ride.

Anyone falsely presenting themselves as being a senior member of the team that worked on that project tends to show their hand by speaking in generalities and not having a strong opinions on specific issues.

Not quite the same as a coding test, but valuable.

By alang | # | Comments (0)
(Posted to Software Development)
© 2003-2006 Alan Green