Skip to content

How to stop naming Java classes with the "Manager" suffix

scottshipp on September 25, 2019

Everywhere you look in a Java application, there are classes named SomethingManager. The account cache has an AccountCacheManager. The application ... [Read Full]
markdown guide

Finally says it outloud! I'm joining your movement! I'm against Managers that turn into big hold all the wrapper things or simply they became the only way to communicate through bad designed API!

Let's start making more sense in our code!


I'm fully on board.
Nice article.
But to be fair with beginners, it's also Java's fault for pointing out programmers in the wrong direction.

One of my all time favorite article describes it brilliantly

"Execution in the Kingdom of Nouns"


I totally agree. But if it would only stop at "manager" or (at java, for that matter)...

In fact, I often fail to see the need of "[ClassName]Manager" in the first place - just manage "[ClassName]" inside "[ClassName]" and be done with it!

One of my personal favorite comment on StackOverflow is this - As a response to one of the answers on this question:

A long time ago I have read an article (I believe a blog entry) which put me on the "right" track on naming objects: Be very very scrupulous about naming things in your program.

For example if my application was (as a typical business app) handling users, companies and addresses…


However, I like the Manager Suffix that we use in Java / Jakarta EE projects with BCE pattern near the Rest Resources.
e.g. blogpost.boundry.BlogPostResource, blogpost.boundry.BlogPostManager then a POJO / an entity named blogpost.entity.BlogPost I learned it from AdamBien :)


I use Spring in my day to day work, and by now I'm just used to the ...Configurer, ...Factory, ...Aware, ... Hey, in fact someone had written an article on some topic and had demonstrated with a piece of code on how to create random Spring class names :-)

I liked your article. Meaningful class names go a long way.


A couple of possible options to consider for utils, helpers, etc.:

  1. See if you can treat them like "managers." e.g. can you maybe drop the "util" or "helper" suffix and it would still make sense? A method call like TimeDisplayUtil.friendlyString(endTime) would maybe be more readable as simply TimeDisplay.friendlyString(endTime).

  2. Or, maybe the method parameter is an object that should have this method. Instead of TimeDisplay.friendlyString(endTime) what if it were just endTime.friendlyString()?

  3. Take a cue from the Java standard library and see if it makes sense to move the methods in the "util" or "helper" class into the interface they operate on, similar to List.of.

  4. For classes which hold static methods that operate on two other objects, see if it makes more sense to move the method or methods into one of the objects.

For a very contrived example, imagine there is a CreditCardProcessor class with the method:

public static void process(CreditCard card, Transaction transaction) {
    try {
    } catch(CardDeclinedException ex) {

This method should probably live in the CreditCard class. If you're worried that this unnecessarily couples the CreditCard and Transaction classes, I would refer to the YAGNI principle and say let's prove that there's too much coupling between them before we add a bunch of extra classes to try and keep them separate.

But, in this case, reason alone should tell us that a credit card has transactions and it should be a non-issue for the CreditCard class to have some kind of dependency on the Transaction class.


As mentioned, these are just some of the options for dealing with "helper" "util" etc. classes in an application. Do what seems best to you because every situation is different. classes contain 90% of business logic in some projects.


Manager is one of many empty and useless words that should disappear from our code.

code of conduct - report abuse