Suppose you have an application that uses the Singleton Design pattern for one of it’s classes. But, the problem is that the singleton is expensive to create, because a resource intensive database access is necessary to create the singleton. What can you do to possibly add some efficiency to the process of creating a singleton?

This question is part 2 in our series of design interview questions. It will help if you read part 1 first, since we refer to some of the code that’s used in part 1.

So, the question here is what can you do to help a situation in which a Singleton is expensive to create.

The Singleton design pattern says that there can only be one instance of the class to which the pattern is applied. But, the Singleton design pattern does not say anything at all about when exactly that instance must be created.

Create the instance right before it is needed

Let’s use the Logging class example that we went through in part 1 – you can just assume that creating the singleton for the Logging class is very resource intensive.
So, instead of creating an instance of the Logging class when the class is loaded, we will just create the instance right before that instance is actually needed.

This means that we will need to change the getSingleton() method to initialize the instance of the Logging class, but only if that instance has not been initialized already. So, the new getSingleton() method would now look like this – where singletonInstance represents the instance of the singleton of course:

public static Logging getSingleton() {
/*Create the singleton instance only if it's
  null, which means no one else has created it
  already
*/
             if( singletonInstance  == null ){
                 singletonInstance  = new Logging();
             }

             return singletonInstance;
         }

Just for reference, this is what the getSingleton() method looked like before – note that the singletonInstance is not being initialized:

public static Logging getSingleton() 
{ 
  return singletonInstance; 
}

And the singleton itself will be changed to look like this:

/* note that it is no longer final and it initially points to null
   the old version looked like this - because it was initialized
   without anyone actually calling the getSingleton method :
   private static final Logging singletonInstance = new Logging();
*/
private static Logging singletonInstance = null; 

Note that the method used to retrieve the Singleton instance will now check to see if the “instance” member variable is null. If it is null that of course means that the singleton has not yet been created, so it will then actually create the instance. This will of course only happen the first time the getInstance method is called. But if instance is not null, the instance will simply be returned.

This technique is known as lazy loading

So, we want to repeat that the key thing to understand here is that the method has been changed to check if an instance already exists. If it does exist, it just returns that instance. If it doesn’t exist, then it just creates a new instance and returns that one. The whole point of this is to save resources by instantiating the Singleton only when it’s actually needed. This technique is commonly known as lazy loading, or deferred initialization, because of the fact that the singleton instance is created only once it’s needed – hence it’s “lazy” or “deferred”.

Hiring? Job Hunting? Post a JOB or your RESUME on our JOB BOARD >>

Subscribe to our newsletter for more free interview questions.

3 thoughts on “Design Pattern Interview Question Part 2”

WordPress › Error

There has been a critical error on your website.

Learn more about debugging in WordPress.