when is a singleton class preferred over a class that has only static methods?

Question

When is a singleton class preferred over a class that has only static methods and a private default constructor?

Please vote.

Answer 1

Use a singleton to better control when initialization occurs. With a static class, any initialization must be at class load-time, which you have little control over. For example, a simple reference to a static final MEMBER will trigger class loading. With a singleton, initialization can trivially be deferred till much later - typically, till first time of use.

Reasons to delay initialization may be:

• it's expensive and you don't always need it for that class
• you can't initialize till some other resource is initialized (say, a database connection). In this case, a lazily-instantiated singleton often provides correct order of operations without any explicit control - if it's not referenced till after the other resource is initialized, everything happens for free.

Use a singleton to improve testability. If you need to make some kind of mock object (in the broad sense) of the singleton in order to test its clients, one way to do it is to put an interface on its use, and supply a test singleton that's of a different class but implements the same interface.

Using a singleton makes initialization testing easier as well.

Use a singleton when you might need to debug initialization. Stack traces from static initialization can be puzzling. Debugging can be puzzling too. If the class is loaded early, it may break before a breakpoint on the first line in main() is even hit.

Answer 2

When is a singleton class preferred over a class that has only static methods and a private default constructor?

When you need an instance. For example, to pass as method argument.

Answer 3

I would say that a singleton class would be preferred only in one case: when you have some configuration to store that is system wide, will rarely (if ever) need to be refreshed.

As an example of what I mean, I have a singleton pattern in one of my applications that represents the NAT device of the user's internet connection. This application is intended for desktop use, and so would rarely (if ever) see a change in the internet connection. Presumably the user could carry their laptop to a new location, and this would change; however, there is a method to recreate the state in this event, but this is very infrequently changed state that can take several seconds to initialize.

This need to keep expensive, infrequently changing, and globally applicable state is best done by either an application scoped bean (my preferred option) or a singleton pattern bean. Static methods aren't as good for preserving this kind of state, though you could also accomplish this using static fields as well to make a pseudo-singleton. (Not sure if there's a better name for this - probably)

In general, my recommendation is not to use singleton like patterns if you can avoid it, as it makes re-use more difficult. If you're using a CDI framework, scope your bean at the application level for easier re-use. (This may not be a concern of yours - if not, you may safely ignore this advice)

Answer 4

If you have some state you need to store, a singleton is the way to go. For instance, if your class needs to load some configuration from a properties file.

Answer 5

The main reason for only having static methods is when you just need a toolbox to pack some functions together.

I use singletons for mainly two reasons:

1. It is really expensive (time or memory) to construct the object, and I want to only ever do it once.
2. The data associated with the class needs to be the same in every instance of the class.

Answer 6

Static method is not dynamic, this is a big different with singleton class instance. So if you need to extends from a class and override some method, the second way won't work.

And the for the second way, you may need to use some static references which may lead to memory leak.