3

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?

Community
  • 1
  • 1
Adam Pierzchała
  • 2,244
  • 4
  • 30
  • 32
  • 1
    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 Jan 09 '12 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 Jan 09 '12 at 13:30
  • @mre Read my question first. I linked to the question you have mentioned. – Adam Pierzchała Jan 09 '12 at 13:31
  • @AdamPierzchała, The question you linked answers your question. – mre Jan 09 '12 at 13:32
  • 2
    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 Jan 09 '12 at 13:33
  • @Guillaume ok, I know how it works - that singleton will have instance and static not. But when would I want to use static access over singleton? – Adam Pierzchała Jan 09 '12 at 13:36
  • @amit Thanks for understanding my issue. I expected that some might find it as duplicate, but my question is the exact opposite of the one linked, and there is no **clear** answer to mine. – Adam Pierzchała Jan 09 '12 at 13:38
  • OK that makes sense, sorry. Let's reopen :) Personally, I use static classes when I want a collection of independent methods acting on a specific matter. The perfect example is "StringUtils", which can contain methods such as join (create a string from a list of elements), isValid (check for null or empty or anything else custom), etc. – Guillaume Jan 09 '12 at 14:06
  • Thanks @Guillaume. I see the use case, but is it any better than using a singleton in such case? Why it's not `StringUtils.instance.isValid(str)`? Of course, despite the fact that it is shorter to write ;) – Adam Pierzchała Jan 10 '12 at 08:25
  • Because a singleton will actually be instanciated (it does a "new SingletonClass()" at some point), and in this case there's no point taking the extra memory to have an instance if the called method is static. In my opinion, any methods that *can* be static (i.e. does not use the state of the class) *should* be static. – Guillaume Jan 10 '12 at 11:16

2 Answers2

9

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.

Bohemian
  • 412,405
  • 93
  • 575
  • 722
1

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

MozenRath
  • 9,652
  • 13
  • 61
  • 104
  • static methods can be clubbed with static imports in some cases. although we need to be careful about using static imports(might reduce readablity) – MozenRath Jan 09 '12 at 13:33