Creating static utility methods should not be overused however ? how to avoid it? [closed]

Answer 1

Nothing wrong with a set of static utility methods that belong together in a class. See for example java.util.Collections. If every method in that class that operates on a List would be specified in the List interface itself, they would have to be implemented by all subclasses. As long as they can be implemented by the public List methods, there is no problem.

Of course, as soon as you start adding methods to the interface (or in case of a class, making methods public) only to be able to put functionality in static methods instead of the class itself, then you're on the wrong path.

Answer 2

To contradict the other answers currently available: Static methods are bad!

They do introduce strong coupling. Yes there are cases where it is acceptable. Yes you can make a seam for inside a static method, by making the strategy used inside exchangeable. But as a rule of thumb static are still bad.

To answer the question, how to get rid of static methods. Simple: put them on a proper Object. All statics are gone. Have we improved our code? not much yet. If we replace

callToStaticMethod()

with

new X().callToNoLongerStaticMethod()

we replaced a static call with a constructor call which is essentially just another static method. But now your X is just another dependency, so you can inject it:

class A{
    private final X x;
    A(X aX){
        x = aX;
    }
} 

Note: there is no need to use Spring or any other framework for this. If you feel like it provide a constructor which uses the default implementation. If you are a purist, introduce an interface for X.

Testing A without relying on the implementation of X becomes trivial and obvious. Same for replacing X in any way.

Answer 3

There is nothing wrong with having lots of static methods.

Static methods are (or should be, read on) stateless, which makes them the easiest methods to test - there's no setup, just call them.

You don't need mocking, because there is no state to deal with.

Regarding being stateless, technically static methods can be stateful if they use static variables to store state. If this is the case, from a good-design perspective they should be converted to instance methods using instance variables to store state, employing the singleton pattern if required.

Answer 4

Static utility methods are not so bad. You can hide a package-private strategy behind the static call. This can be easily tested (and replaced) given that the test case belongs to the same package. Moreover, it makes the code very readable. Of course, the clients of the static utility method can still only use one implementation in their tests. So here is some inflexibility.

Bohemian is right when talking about state. If your static utilities have state you are doing something wrong.

About your question: If you want to avoid static methods you can use the spring framework and define different implementations of utilities that you use and test in different contexts. In this case, however, access to these objects is not so convenient as you must first obtain a reference to the context that knows your utility object.