Java Singleton Class Vs. Java Static Methods/Variables: Are They The Same?

Java LogoThe title has an important distinction. Note the Java programming language reference. Singleton classes and statically typed classes are implemented differently in various languages. But for the purposes of this blog post, I will discuss this topic in terms of the Java programming language.

If you Google this topic, you can find a lot of information on the answer to the question I ask in this blog entry. My motivations for blogging about this topic is two-fold: I get many engineers hesitant to implement it, other than not liking it, and it’s a design pattern that seems to come up a lot in interviews.

Professionals argue one side or the other, usually avoiding this pattern for incorrect reasons. First, lets discuss both approaches: Singleton Design Pattern and Static Methods/Variables.

Singleton Pattern

So what is a singleton design pattern? It is the implementation of a class, whereby only one instance of that class is ever available. So basically, it is just like any other class in your solution, except that is can only be instantiated once. This means the singleton can implement an interface, it can extend another class’ behavior, etc. So why use it?

By implementing this pattern, you are attempting to give access to common functionality across your application.

class SingletonImp {
   private static SingletonImp instance = new SingletonImp();
   …
   private SingletonImp() {}
   …
   public static synchronized SingletonImp getInstance() {
       return instance;
   }
   …
}

A good example of this pattern’s implementation is the Toolkit class. java.awt.Toolkit is an abstract class singleton, because the Abstract Windows Toolkit library only needs one object instance to create a subclass/binding, obtained by a call to System.getProperties(‘awt.toolkit’). In this example, the common functionality is used across multiple platforms, i.e. getting the system’s/platform’s AWT toolkit.

Aside from being used in this Factory pattern, the Singleton pattern is also used in the Prototype and Builder patterns.

It can also be lazily constructed, requiring no memory or resources until needed.

class SingletonImp {
   private static SingletonImp;
   …
   private SingletonImp() {}
   …
   public static synchronized SingletonImp getInstance() {
       if(instance == null) {
           instance = new SingletonImp();
       }
       return instance;
   }
   …
}

So the main motivation for a singleton, as I see it:

  1. Common functionality is needed across your application, without the overhead of multiple instantiations
  2. If criteria #1 is met, you want to extend behavior or implement an interface

The need for a Singleton with other patterns, like the Factory and Prototype patterns, goes without argument. It is typically outside of these patterns that the debate ensues.

Static Methods/Variables

Most engineers/developers/programmers can understand the concept of a static variable or method. We have all implemented them at some point.

So why not make every method in a class static and synchronized, as well as its variables, vs creating a Singleton? This gives the same functionality as a Singleton class. The short answer: It depends.

If you need to realize behavior expressed by an interface, and you only want one instance of this behavior available, then it must be a Singleton. Also, you may not want to manage the state of static behavior, which comes with all the problems that global variables have given us in other languages.

Conclusions

There are many situations when one implementation may make more sense than another. However, here are three main distinctions about a Singleton class that may help you make a better design decision about approaching both solutions in your project:
JumpGold

  1. Singletons can extend behavior of an existing class
  2. Static behavior cannot be implemented via an interface, therefore a Singleton class is better suited when single-instantiation and extension of behaviors is required/optimal.
  3. You can implement your Singleton class lazily, i.e. whenever you need it. The distinction here is that static methods/variables take space on the memory stack, regardless of whether or not you need them.

That was a quick rundown of a Singleton vs solely using static methods/classes. Although everything always depends on your application, knowing the Singleton pattern distinctions may help you make a more informed design decision, as well as making you more engaged with your peers on this topic.

About Rick

I am a father, husband and software engineer, trying to stay active, both in my personal and professional communities. I enjoy programming and building Web applications.
This entry was posted in Design Patterns and tagged , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s