re: How to stop naming Java classes with the "Manager" suffix VIEW POST


XXXUtils.java classes contain 90% of business logic in some projects.


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.

code of conduct - report abuse