Static Classes Versus the Singleton Pattern in Java

1. Introduction

In this quick tutorial, we’ll discuss some eminent differences between programming to the Singleton design pattern and using static classes in Java. We’ll review both the coding methodologies and compare them with respect to different aspects of programming.

By the end of this article, we’ll be able to make the right decision when picking between the two options.

2. The Basics

Let’s hit ground zero. Singleton is a design pattern that assures a single instance of a Class for the lifetime of an application.
It also provides a global point of access to that instance.

static – a reserved keyword – is a modifier that makes instance variables as class variables. Hence, these variables get associated with the class (with any object). When used with methods, it makes them accessible just with the class name. Lastly, we can also create static nested inner classes.

In this context, a static class contains static methods and static variables.

3. Singleton Versus Static Utility Classes

Now, let’s go down the rabbit hole and understand some prominent differences between the two giants. We begin our quest with some Object-Oriented concepts.

3.1. Runtime Polymorphism

Static methods in Java are resolved at compile-time and can’t be overridden at runtime. Hence, a static class can’t truly benefit from runtime polymorphism:

public class SuperUtility {

    public static String echoIt(String data) {
        return "SUPER";
    }
}

public class SubUtility extends SuperUtility {

    public static String echoIt(String data) {
        return data;
    }
}

@Test
public void whenStaticUtilClassInheritance_thenOverridingFails() {
    SuperUtility superUtility = new SubUtility();
    Assert.assertNotEquals("ECHO", superUtility.echoIt("ECHO"));
    Assert.assertEquals("SUPER", superUtility.echoIt("ECHO"));
}

Contrastingly, singletons can leverage the runtime polymorphism just like any other class by deriving from a base class:

public class MyLock {

    protected String takeLock(int locks) {
        return "Taken Specific Lock";
    }
}

public class SingletonLock extends MyLock {

    // private constructor and getInstance method 

    @Override
    public String takeLock(int locks) {
        return "Taken Singleton Lock";
    }
}

@Test
public void whenSingletonDerivesBaseClass_thenRuntimePolymorphism() {
    MyLock myLock = new MyLock();
    Assert.assertEquals("Taken Specific Lock", myLock.takeLock(10));
    myLock = SingletonLock.getInstance();
    Assert.assertEquals("Taken Singleton Lock", myLock.takeLock(10));
}

Moreover, singletons can also implement interfaces, giving them an edge over static classes:

public class FileSystemSingleton implements SingletonInterface {

    // private constructor and getInstance method

    @Override
    public String describeMe() {
        return "File System Responsibilities";
    }
}

public class CachingSingleton implements SingletonInterface {

    // private constructor and getInstance method

    @Override
    public String describeMe() {
        return "Caching Responsibilities";
    }
}

@Test
public void whenSingletonImplementsInterface_thenRuntimePolymorphism() {
    SingletonInterface singleton = FileSystemSingleton.getInstance();
    Assert.assertEquals("File System Responsibilities", singleton.describeMe());
    singleton = CachingSingleton.getInstance();
    Assert.assertEquals("Caching Responsibilities", singleton.describeMe());
}

Singleton-scoped Spring Beans implementing an interface are perfect examples of this paradigm.

3.2. Method Parameters

As it’s essentially an object, we can easily pass around a singleton to other methods as an argument:

@Test
public void whenSingleton_thenPassAsArguments() {
    SingletonInterface singleton = FileSystemSingleton.getInstance();
    Assert.assertEquals("Taken Singleton Lock", singleton.passOnLocks(SingletonLock.getInstance()));
}

However, creating a static utility class object and passing it around in methods is worthless and a bad idea.

3.3. Object State, Serialization, and Cloneability

A singleton can have instance variables, and just like any other object, it can maintain a state of those variables:

@Test
public void whenSingleton_thenAllowState() {
    SingletonInterface singleton = FileSystemSingleton.getInstance();
    IntStream.range(0, 5)
        .forEach(i -> singleton.increment());
    Assert.assertEquals(5, ((FileSystemSingleton) singleton).getFilesWritten());
}

Furthermore, a singleton can be serialized to preserve its state or to be transferred over a medium, such as a network:

new ObjectOutputStream(baos).writeObject(singleton);
SerializableSingleton singletonNew = (SerializableSingleton) new ObjectInputStream
   (new ByteArrayInputStream(baos.toByteArray())).readObject();

Finally, the existence of an instance also sets up the potential to clone it using the Object’s clone method:

@Test
public void whenSingleton_thenAllowCloneable() {
    Assert.assertEquals(2, ((SerializableCloneableSingleton) singleton.cloneObject()).getState());
}

Contrarily, static classes only have class variables and static methods, and therefore, they carry no object-specific state. Since static members belong to the class, we can’t serialize them. Also, cloning is meaningless for static classes due to the lack of an object to be cloned. 

3.4. Loading Mechanism and Memory Allocation

The singleton, like any other instance of a class, lives on the heap. To its advantage, a huge singleton object can be lazily loaded whenever required by the application.

On the other hand, a static class encompasses static methods and statically bound variables at compile time and is allocated on the stack.
Therefore, static classes are always eagerly loaded at the time of class loading in the JVM.

3.5. Efficiency and Performance

As iterated earlier, static classes don’t require object initialization. This removes the overhead of the time required to create the object.

Additionally, by static binding at compile-time, they’re more efficient than singletons and tend to be faster.

We must choose singletons for design reasons only and not as a single instance solution for efficiency or a performance gain.

3.6. Other Minor Differences

Programming to a singleton rather than a static class can also benefit the amount of refactoring required.

Unquestionably, a singleton is an object of a class. Therefore, we can easily move away from it to a multi-instance world of a class.

Since static methods are invoked without an object but with the class name, migrating to a multi-instance environment could be a relatively larger refactor.

Secondly, in static methods, as the logic is coupled to the class definition and not to the objects, a static method call from the object being unit-tested becomes harder to be mocked or even overwritten by a dummy or stub implementation.

4. Making the Right Choice

Go for a singleton if we:

• Require a complete object-oriented solution for the application
• Need only one instance of a class at all given times and to maintain a state
• Want a lazily loaded solution for a class so that it’s loaded only when required

Use static classes when we:

• Just need to store many static utility methods that only operate on input parameters and do not modify any internal state
• Don’t need runtime polymorphism or an object-oriented solution

5. Conclusion

In this article, we reviewed some of the essential differences between static classes and the Singleton pattern in Java. We also inferred when to use either of the two approaches in developing software.