What is the better approach to implement Singleton pattern?

Singleton is one of the frequently used and easily understandable design pattern. Most of the tutorials and books give example of making the constructor as private and exposing a static method which will provide single instance. The common example they use is Runtime class of JRE.

Is making constructor as private is the only way to implement singleton pattern? Is that the best way to implement singleton pattern?

My answer is “No“. Let us take an example of JRE implementation class Math. Math is a singleton class, but the instance is not exposed as a static method. Rather they made all the methods as static.

JRE exposing Runtime class instance through a static methods instead of keeping all the methods as static because it contains native method, native methods cannot be static.

My recommendation to implement singleton pattern is: make all the methods as static, if for any reason you cannot make all the methods as static, then go for static instance approach.

I feel keeping all methods as static methods is better design and developer friendly.

Advertisements

7 Responses to What is the better approach to implement Singleton pattern?

  1. Santhosh Kumar says:

    Wat if i’m supposed to pass my singleton object to a method. Check out this link

  2. S M Humayun says:

    IMO static methods approach is not a (better) way to implement singleton pattern. First, you loose the freedom to pass singleton to others. Secondly, you are tightly coupling the singleton code with the calling code. Thirdly, static scope is certainly not a good thing to rely on. See for details.

  3. d descombaz says:

    To add to the first two posts, you wouldn’t be able to inherit, or implement anything either.

    I think you are describing the preferred way to make static library in Java. Obviously, it depends upon your needs. A singleton, and a non-instantiable class (outwardly non-instantiable at least) with only static methods and/or properties definitely share characteristics, but they are not the same thing.

    Since it doesn’t really create an instance, it increases coupling, and you lose some of the potential benefits of OO design, my feeling is that I wouldn’t generally recommend that someone approaches a singleton this way.

  4. Karthikeyan says:

    Once you refer to static methods callers are tightly coupled to the Singleton class. Suppose we want to have the slightly modified version of Singleton [say limit to 2 such instances of Singleton [or its subclasses]] we will not be able to do so.

  5. Rob says:

    One thing I look to do with “Singletons” is to:
    – create an interface as well as the singleton
    – the singleton has a field that is of the interface type
    – the singleton on initialisation creates an implementation of the interface (you can make this as sophisticated as you like using properties files or Ioc etc)
    – the singleton methods proxy through to the underlying implementation of the interface (and yes, I make them all static methods)

    You end up with the singleton providing the scope but doing nothing except creating the underlying implementation and being a proxy to the underlying implementation.

    I want to minimise the code in the “singleton” as it becomes tightly coupled (not replacable) so whereever possible use the interface and not the singleton.

    You can make the construction of the underlying implementation as simple or as sophisticated as you like (ala pluggable implementation using property files etc to find and construct the implementation).

    This may be better described as a “static proxy to a default implementation of an interface” rather than a “singleton”…

    Cheers, Rob.

  6. Venkat says:

    I take back my word on static method implementation for singleton pattern. Recently I encountered a situation where we need to serialize singleton class (contains static variables/methods); since the variables are static we are not able to serialize the singleton instance.

  7. mohanmca says:

    I often use Holder Idiom pattern for singletons which require lazy loading for other GOF Singleton is enough.

    There are many assumptions made in this blog.. one such is all code written during 1.0 of JDK is good enough to consider as perfect. It is 14 yrs from then. People were not known about GOF patterns.

    Josh Bloch was not there with Sun Microsystem. Internet was not famous.

    So Math class used Static methods.

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

%d bloggers like this: