Singletons

I've been playing about with a code base that has a large number of singletons, for what appears to be no apparent reason.
Something about singletons doesn't sit quite right with me, but in the most part, if they're not misbehaving, I'll probably leave them be.

The thing that bothers me a lot more though, is the fact that everyone else is forced to know about your singleton-ness..

ImASingleton.getInstance().doSomething();

*shivers*

If you have to store global state, it would be nice if we could hide that from the clients. Why do we have a single instance with instance variables accessed through a static getInstance method, when we could hide (ooh, encapsulation) the implementation behind multiple instances with private static variables?
By using instance methods, we also get all the interface / testing / mocking goodness.

new ImASingletonButYouCantTell().doSomething();

OK, I'm rambling... am I missing something? (please rant below)

Static Utility Methods

A few of us were chatting about static methods the other day.
I'm not a big fan. I think that they tie you unnecessarily to a concrete class.

Most people were saying that there is no harm in having static methods in utility classes, and this is one place where I would disagree.
The example used was the java.lang.Math class with it's utility methods.

java.lang.Math is non-instantiable, you can only access it's utility methods through static calls.
For the most part, this is fine, but take the example of Math.sqrt(x)
This method returns NaN if x is < 0. For the majority of cases this is fine, but if I start working with complex numbers, then this is no longer the ideal behaviour.
Admittedly, in this case I would not want the return value to be a double, but I may want it to throw a ComplexNumberException or something similar. If I have used the static method throughout my code, I now have to go and update every single reference to the concrete class. What a pain in the class!

However, if I had used a utility class with instance methods, I could have injected the utility class in the constructor and I could now change it out for my new ComplexMathUtility class through configuration / DI.

This isn't the best example, as the required return types are different, but think of a String utility class, perhaps something that formats a header for a report.
We could (naively) implement this using static utility methods. If we later require two different types of report heading, this is going to make our life difficult.
If we implement this using an instantiable ReportFormatter, we can swap in new ones at runtime / configuration. We've just implemented a ReportFormatterStrategy :-)

My feeling is that implementing utilities as instance methods keeps the design flexible and allows for more code reuse as things naturally gravitate towards smaller, more easily testable, logically grouped units of functionality...
Or am I just dreaming? :-)