Creating static utility methods should not be over

Question

With the time ...lots of utility method are introduced in java project for more complex and simple task.

When using static methods we introduce tight coupling in our code and it make our code more difficult to test, especially if the utility methods are quite complex.

I am just thinking that it now difficult to manage and test these utilities. please guide me in avoiding these utilities methods and how can i organize existing project to remove all STATIC utilities.

Can you help me avoiding static method ?

Answer 1

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.

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

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.