When use a static class instead of the singleton pattern?

Question

I've read this question and some similar ones and I wonder if there is any situation when I should use static class over the singleton pattern?

Well why didn't you read the answers to that question? They perfectly sum up the cases to use singletons or static classes. TO sum up again: use singleton when you want one (and only one) INSTANCE of a particular class in your app. Use a static utility class when you don't want an instance, and all the methods can be called statically (the static class is stateless, i.e. has no internal non-static variables) — Guillaume
– Guillaume, Commented Jan 9, 2012 at 13:28
They very well cover the advantages of using singletons over statics, but there is almost nothing in reverse tone (yes, almost - but I'm curious if there is any strong argument against using singletons in any case). — Adam Pierzchała
– Adam Pierzchała, Commented Jan 9, 2012 at 13:30
@mre Read my question first. I linked to the question you have mentioned. — Adam Pierzchała
– Adam Pierzchała, Commented Jan 9, 2012 at 13:31
@AdamPierzchała, The question you linked answers your question. — mre
– mre, Commented Jan 9, 2012 at 13:32
voting to reopen, the question asks the exact oposite of the marked duplicate. The OP wants to know when to prefer static over singleton, and not the other way around - as the duped link suggests — amit
– amit, Commented Jan 9, 2012 at 13:33

Bohemian · Accepted Answer · 2012-01-10 21:46:56Z

Use a static "utility" class (a class with nothing but static methods) when you have "just code" methods - methods where you don't need any particular implementation of a base class or interface. The key indicator is that the code is stateless - ie there are no (static) fields in the class to give it state. Being stateless also means the methods are automatically thread safe - another benefit.

There are many examples in the JDK (Collections being one notable example) and the apache commons libraries of this pattern working very well.

Also, to avoid "class bloat", rather than have a class for a particular trivial implementation, you can have static (abstract) factory methods that return a particular implementation, for example:

public static Comparator<String> createCaselessStringCompatator() { return new Comparator<String> () { public int compare(String o1, String o2) { return o1.toUpperCase().compareTo(o2.toUpperCase()); } }; } public static Comparator<String> createNumericStringCompatator() { return new Comparator<String> () { public int compare(String o1, String o2) { return new Double(o1).compareTo(new Double(o2)); } }; }

This pattern avoids creating a whole new class file for what amounts to just a single line of actual useful code (ie a "closure") and it bundles them up so if you know your utility class name, your IDE will prompt you for which impl you want to choose:

Collections.sort(myStringList, MyComparators.|<-- ctrl+space to offer options

Whereas without this pattern, you'd have to remember the class name of each of the implementations.

thanks, I'm accepting this one, as nothing better ( I don't mean that it's not good enough ;) ) appeared since then.

MozenRath · Accepted Answer · 2012-01-09 13:32:16Z

1

I think this would be a case where you require a place for some utility functions which again are static.

answered Jan 9, 2012 at 13:32

MozenRath

10.1k13 gold badges69 silver badges109 bronze badges

1 Comment

MozenRath Over a year ago

static methods can be clubbed with static imports in some cases. although we need to be careful about using static imports(might reduce readablity)

Collectives™ on Stack Overflow

When use a static class instead of the singleton pattern?

2 Answers 2

1 Comment

1 Comment

Linked

Hot Network Questions

Collectives™ on Stack Overflow

2 Answers 2

1 Comment

1 Comment

Linked

Related