DEV Community

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 post

Sinuhe Jaime Valencia • Sep 26 '19

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 • Sep 26 '19

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 • Sep 26 '19 • Edited

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…

Guruprasad Kulkarni • Sep 27 '19 • Edited

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 • Sep 26 '19

Have you seen class names in Spring :-)

scottshipp • Sep 26 '19

AbstractSingletonProxyFactoryBean!!

Sunit Katkar • Sep 26 '19

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 • Sep 27 '19

What about util classes, helpers, etc?

scottshipp • Sep 27 '19

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

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).
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()?
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.
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 • Sep 27 '19

They are a bunch of functions.

abelncm • Feb 18 '21

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 • Sep 26 '19

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

Henrique Horbovyi • Aug 6 '20

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