Is it bad practice for a class to have only static fields and methods?

Question

I have a class that consists only of static member variables and static methods. Essentially, it is serving as a general-purpose utility class.

Is i

Answer 1

Static methods don't worry me much (except for testing).

In general, static members are a concern. For example, what if your app is clustered? What about start-up time -- what kind of initialization is taking place? For a consideration of these issues and more, check out this article by Gilad Bracha.

Answer 2

As long as the class has no internal state and is essentially what is known as a leaf class (utility classes fall into this category), in other words it is independent of other classes. It is fine.

The Math class being a prime example.

Answer 3

Sounds reasonable.

Note: Classes that do this often have a private no-arg constructor just so that the compiler yields an error if a programmer tries to create an instance of the static class.

Answer 4

According to a rigid interpretation of Object Oriented Design, a utility class is something to be avoided.

The problem is that if you follow a rigid interpretation then you would need to force your class into some sort object in order to accomplish many things.

Even the Java designers make utility classes (java.lang.Math comes to mind)

Your options are:

double distance = Math.sqrt(x*x + y*y);  //using static utility class

vs:

RootCalculator mySquareRooter = new SquareRootCalculator();
mySquareRooter.setValueToRoot(x*x + y*y);
double distance;
try{
   distance = mySquareRooter.getRoot();
}
catch InvalidParameterException ......yadda yadda yadda.      

Even if we were to avoid the verbose method, we could still end up with:

Mathemetician myMathD00d = new Mathemetician()
double distance = myMathD00d.sqrt(...);

in this instance, .sqrt() is still static, so what would the point be in creating the object in the first place?

The answer is, create utility classes when your other option would be to create some sort of artificial "Worker" class that has no or little use for instance variables.

Answer 5

While I agree with the sentiment that it sounds like a reasonable solution (as others have already stated), one thing you may want to consider is, from a design standpoint, why do you have a class just for "utility" purposes. Are those functionals truly general across the entire system, or are they really related to some specific class of objects within your architecture.

As long as you have thought about that, I see no problem with your solution.

Answer 6

This link http://java.dzone.com/articles/why-static-bad-and-how-avoid seems to go against most of the answers here. Even if it contains no member variables (i.e. no state), a static class can still be a bad idea because it cannot be mocked or extended (subclassed), so it is defeating some of the principles of OO