I hope this will answer just the main question here.
There are already few great answers in SO. I'll just quote them.
Best answer, by Heinzi:
A singleton is used to introduce some kind of global state to an
application. If it is stateless, I also don't see the point of using a
- you expect to extend it with state in the foreseeable future or
- you need an object instance for some particular technical reason (for example, for the C#
SyncLock statement, although this is
already quite far-fetched) or
- you need inheritance, i.e., you want to be able to easily replace your singleton with another one using the same interface but a
different implementation. For example, the
Toolkit.getDefaultToolkit() method in Java will return a singleton
whose exact type is system dependent.
High relevant comment, by back2dos:
(...) singletons are misused to introduce global states. The purpose of a singleton is not to make an object globally available, but to enforce that an object is instantiated only once. Global objects are a necessary evil. Unless really required, one should try not to use them, since they generally lead to high coupling, with SomeSingleton.getInstance().someMethod() all over the place.
tzaman also wrote a good answer:
I could see a case for a stateless singleton being used instead of a
static methods class, namely for Dependency Injection.
If you have a helper class of utility functions that you're using
directly, it creates a hidden dependency; you have no control over who
can use it, or where. Injecting that same helper class via a stateless
singleton instance lets you control where and how it's being used, and
replace it / mock it / etc. when you need to.
Making it a singleton instance simply ensures that you're not
allocating any more objects of the type than necessary (since you only
ever need one).
And finally Sebastien also answered himself quite well:
Actually i've found another answer not mentionned here: static methods are harder to test.
It seems most test frameworks work great for mocking instance methods but many of them no not handle in a decent way the mock of static methods.
That being said, I advise using the Toolbox pattern.