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

Everywhere you look in a Java application, there are classes named SomethingManager. The account cache has an AccountCacheManager. The application properties have an ApplicationPropertiesManager. The user transaction is completed by a UserTransactionManager.

You probably named a class this way at some point.

Please go change it.

What's wrong with "Manager?"

Manager is a meaningless suffix. Sure, you might argue that we need a thing to manage another thing, but what do you mean when you say that? You're giving code a manager? Is this a workplace? Do objects in your application need a boss?

How to change it?

Whenever I see "Manager" in a class name it's almost always redundant. I saw a class that managed the life cycle of another component recently. It was predictably named with the "LifeCycleManager" suffix. For sure this is a case where we need to name the class manager, right? After all, it manages the life cycle and that's what we actually say in the real world?

No! Wrong!

This class had initialize() and stop() methods. Let's assume the class it "managed" was called MyComponent. It's actually clearer and more readable to just call the "manager" class, MyComponentLifeCycle. The code where it's "managed" becomes MyComponentLifeCycle.initialize() and MyComponentLifeCycle.stop(). I can initialize or stop the life cycle directly, and when I do, I say what I mean and I mean what I say. I don't ask a manager to do it, I just do it.

This simple idea applies across most use cases where I've seen the Manager suffix on a class. Just now, I opened up a code base and found a ConnectionManager class. Some of the methods it exposes are getConnection(), configure(), and close(). Setting aside the fact that this class probably could be refactored into some other object that makes more sense, all its really doing is holding a javax.sql.DataSource and providing some utility code around it, with the ultimate goal of providing a valid java.sql.Connection to the application.

Can't this class just be called DbConnection and change that getConnection() method (which returns a java.sql.Connection by the way) to just get() or maybe asSqlConnection()? Now instead of having a ConnectionManager.getConnection() (which is totally redundant too by the way) you instead have DbConnection.get(). Later you call DbConnection.close(). No need for a "manager."

No Managers!

As you can see, clean code should have no managers. It's redundant and unnecessary. It tells you nothing about what the class actually does.

My goal is manager extinction. Who's with me?

Comments

[Sinuhe Jaime Valencia]

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!

[Jean-Michel 🕵🏻‍♂️ Fayard]

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"
steve-yegge.blogspot.com/2006/03/e...

[Zohar Peled]

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:

Naming Classes - How to avoid calling everything a "<WhatEver>Manager"?

Dec 8 '09 Comments: 25 Answers: 13

1215

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…

Open Full Question

[Guruprasad Kulkarni]

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 :)

[Sunit Katkar]

Have you seen class names in Spring :-)

[scottshipp]

AbstractSingletonProxyFactoryBean!!

[Sunit Katkar]

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.

[Sandro Giacomozzi]

What about util classes, helpers, etc?

[scottshipp]

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 {
        card.attempt(transaction);
    } catch(CardDeclinedException ex) {
        transaction.mark(Transaction.DECLINED);
        return;
    }
    transaction.mark(Transaction.PENDING);
}

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.

[Vlastimil Pospichal]

They are a bunch of functions.

[abelncm]

How should i call a service that has basic crud operations with business login like validation before create, or something after delete? Woukd be somethibg like SourceManager.create(Source s)
Then update, then list, then delete, show, etc. Do you have a better name?

[Vlastimil Pospichal]

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

[Henrique Horbovyi]

Really good post. Congrats!
For a better naming 🙌️