Is using a lot of static methods a bad thing?

I tend to declare as static all the methods in a class when that class doesn't require to keep track of internal states. For example, if I need to transform A into B and don't rely on some internal state C that may vary, I create a static transform. If there is an internal state C that I want to be able to adjust, then I add a constructor to set C and don't use a static transform.

I read various recommendations (including on StackOverflow) NOT to overuse static methods but I still fail to understand what it wrong with the rule of thumb above.

Is that a reasonable approach or not?

There are two kinds of common static methods:

• A "safe" static method will always give the same output for the same inputs. It modifies no globals and doesn't call any "unsafe" static methods of any class. Essentially, you are using a limited sort of functional programming -- don't be afraid of these, they're fine.
• An "unsafe" static method mutates global state, or proxies to a global object, or some other non-testable behavior. These are throwbacks to procedural programming and should be refactored if at all possible.

There are a few common uses of "unsafe" statics -- for example, in the Singleton pattern -- but be aware that despite any pretty names you call them, you're just mutating global variables. Think carefully before using unsafe statics.

An object without any internal state is a suspicious thing.

Normally, objects encapsulate state and behavior. An object that only encapsulates behavior is odd. Sometimes it's an example of Lightweight or Flyweight.

Other times, it's procedural design done in an object language.

This is really only a follow up to John Millikin's great answer.

Although it can be safe to make stateless methods (which are pretty much functions) static, it can sometimes lead to coupling that is hard to modify. Consider you have a static method as such:

public class StaticClassVersionOne {
    public static void doSomeFunkyThing(int arg);
}

Which you call as:

StaticClassVersionOne.doSomeFunkyThing(42);

Which is all well and good, and very convenient, until you come across a case where you have to modify the behaviour of the static method, and find that you are tightly bound to StaticClassVersionOne. Possibly you could modify the code and it would be fine, but if there was other callers dependent on the old behaviour, they'll need to be accounted for in the body of the method. In some cases that method body can get pretty ugly or unmaintainable if it tries to balance all these behaviours. If you split out the methods you may have to modify code in several places to take account of it, or make calls to new classes.

But consider if you had created an interface to provide the method, and given it to callers, now when the behaviour has to change, a new class can be created to implement the interface, which is cleaner, more easily tested, and more maintainable, and that instead is given to the callers. In this scenario the calling classes don't need to be altered or even recompiled, and the changes are localised.

It may or it may not be a likely situation, but I think it is worth considering.

The other option is to add them as non-static methods on the originating object:

i.e., changing:

public class BarUtil {
    public static Foo transform(Bar toFoo) { ... }
}

into

public class Bar {
    ...
    public Foo transform() { ...}
}

however in many situations this isn't possible (e.g., regular class code generation from XSD/WSDL/etc), or it will make the class very long, and transformation methods can often be a real pain for complex objects and you just want them in their own separate class. So yeah, I have static methods in utility classes.