Stateless singleton VS Static methods

Question

Hey,

Don't find any good answer to this simple question about helper/utils classes:

Why would i create a singleton (stateless) rather than static methods?

Why an object instance could be needed while the object has no state?

Sometimes i really don't know what to use...

Answer 1

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 singleton, unless

• 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.

Answer 2

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).

Answer 3

In most programming languages classes elude a lot of the type system. While a class, with its static methods and variables is an object, it very often cannot implement an interface or extend other classes. For that reason, it cannot be used in a polymorphic manner, since it cannot be the subtype of another type. For example, if you have an interface IFooable, that is required by several method signatures of other classes, the class object StaticFoo cannot be used in place of IFooable, whereas FooSingleton.getInstance() can (assuming, FooSingleton implements IFooable).

Please note, that, as I commented on Heinzi's answer, a singleton is a pattern to control instantiation. It replaces new Class() with Class.getInstance(), which gives the author of Class more control over instances, which he can use to prevent the creation of unneccessary instances. The singleton is just a very special case of the factory pattern and should be treated as such. Common use makes it rather the special case of global registries, which often ends up bad, because global registries should not be used just willy-nilly.

If you plan to provide global helper functions, then static methods will work just fine. The class will not act as class, but rather just as a namespace. I suggest, you preserve high cohesion, or you might end up with weirdest coupling issues.

greetz
back2dos

Answer 4

Singleton is not stateless, it holds the global state.

Some reasons which I can think of using Singleton are:

• To avoid memory leaks
• To provide the same state for all modules in an application e.g database connection