In our Java codebase I keep seeing the following pattern:

 This is a stateless utility class
 that groups useful foo-related operations, often with side effects.
public class FooUtil {
  public int foo(...) {...}
  public void bar(...) {...}

 This class does applied foo-related things.
class FooSomething {
  int DoBusinessWithFoo(FooUtil fooUtil, ...) {
    if (fooUtil.foo(...)) fooUtil.bar(...);

What bothers me is that I have to pass an instance of FooUtil everywhere, because testing.

  • I cannot make FooUtil's methods static, because I won't be able to mock them for testing of both FooUtil and its client classes.
  • I cannot create an instance of FooUtil at the place of consumption with a new, again because I won't be able to mock it for testing.

I suppose that my best bet is to use injection (and I do), but it adds its own set of hassles. Also, passing several util instances inflates the size of method parameter lists.

Is there a way to handle this better that I'm not seeing?

Update: since the utility classes are stateless, I could probably add a static singleton INSTANCE member, or a static getInstance() method, while retaining the ability to update the underlying static field of the class for testing. Does not seem super-clean, too.

  • 4
    And your assumption that all dependencies need to be mocked to do unit testing effectively is not correct (though I'm still looking for the question that discusses that).
    – Telastyn
    Commented Jan 5, 2015 at 20:51
  • 4
    Why are these methods not members of the class whose data they manipulate?
    – Jules
    Commented Jan 5, 2015 at 20:52
  • 3
    Have a seperate set of Junit that call the static fns if FooUtility. Then you can use it without mocking. If its someting that you need to mock then I suspect its not just a utility but doing some IO or business logic and should in fact be a class member reference and initialized via constructor, init or setter method.
    – tgkprog
    Commented Jan 5, 2015 at 21:08
  • 2
    +1 for Jules comment. Util classes are a code smell. Depending on the semantics there should be a better solution. Maybe the FooUtil methods should be put into FooSomething, maybe there are properties of FooSomething that should be changed/extended so that the FooUtil methods are not needed anymore. Please give us a more concrete example of what FooSomething to help us providing a good answer to this questions.
    – valenterry
    Commented Jan 5, 2015 at 21:28
  • 14
    @valenterry: The only reason util classes are a code smell is because Java doesn't provide a good way to have standalone functions. There are very good reasons to have functions that are not specific to classes. Commented Jan 5, 2015 at 21:30

2 Answers 2


First of all let me say that there are different programming approaches for different problems. For my job I prefer a strong OO design for orginazation and maintenance and my answer reflects this. A functional approach would have a very different answer.

I tend to find that most utility classes are created because the object the methods should be on doesn't exist. This almost always comes from one of two cases, either someone is passing collections around or someone is passing beans around (These are often called POJOs but I believe a bunch of setters and getters is best described as a bean).

When you have a collection you are passing around, there must be code that wants to be a part of that collection, and this ends up being sprinkled throughout your system and eventually collected into utility classes.

My suggestion is to wrap your collections (Or beans) with any other closely associated data into new classes and put the "utility" code in actual objects.

You could extend the collection and add the methods there but you lose control of your object's state that way--I suggest you encapsulate it completely and only expose business logic methods that are necessary (Think "Don't ask your objects for their data, give your objects commands and let them act on their private data", an important OO tenant and one that, when you think about it, requires the approach I'm suggesting here).

This "wrapping" is useful for any general purpose library objects that hold data but you can't add code to--Putting code with the data it manipulates is another major concept in OO design.

There are many coding styles where this wrapping concept would be a bad idea--who want's to write a whole class when just implementing a one-time script or test? But I think encapsulation of any basic types/collections that you cannot add code to yourself is mandatory for OO.

  • This answer is so awesome. I had this problem (obviously), read this answer with some dubiousness, went back and looked at my code and asked "what object is missing that should have these methods". Lo and behold, elegant solution found and object-model-gap filled. Commented Apr 30, 2019 at 6:29
  • @Deduplicator In 40 years of programming I've rarely (never?) seen the case where I was blocked by too many levels of indirection (aside from the occasional fight with my IDE to jump to an implementation rather than an interface) but I've often (Very Often) seen the case where people wrote horrible code rather than creating a clearly needed class. Although I believe too much indirection might have bitten some people, I'd error on side of proper OO principles such as each class doing one thing well, proper containment, etc.
    – Bill K
    Commented Apr 30, 2019 at 23:57
  • @BillK Generally, a good idea. But without an escape-hatch, encapsulation can really get in the way. And there is a certain beauty to free algorithms you can match to any type you want, though admittedly in strict-OO languages anything but OO is quite awkward. Commented May 1, 2019 at 10:28
  • @Deduplicator When writing 'utility' Functions that must be written outside of specific business requirements you are correct. Utility classes full of functions (such as collections) are simply awkward in OO because they are not associated with data. these are the "Escape Hatch" that people who aren't comfortable with OO use (also, tool vendors must use these for very generic functionality). My suggestion above was to wrap these hacks in classes when you are working on business logic so that you can re-associate your code with your data.
    – Bill K
    Commented May 1, 2019 at 16:42

You could use a Provider pattern and inject your FooSomething with a FooUtilProvider object (could be in a constructor; only once).

FooUtilProvider would only have one method: FooUtils get();. The class would then use whatever FooUtils instance it provides.

Now that's one step away from using a Dependency Injection framework, when you'd only have to wire DI cointainer twice: for production code, and for your tests suite. You just bind FooUtils interface to either RealFooUtils or MockedFooUtils, and the rest happens automagically. Every object that depends on FooUtilsProvider gets the proper version of FooUtils.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.