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 bothFooUtiland its client classes. - I cannot create an instance of
FooUtilat the place of consumption with anew, 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.
17
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.
5
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.
0