Time for Singleton.


GoF Intent 

“Ensure a class only has one instance, and provide a global point of access to it”

Why Singleton ?

Well, why not ? This is a very common pattern and as it's intent suggests it is all about making only one instance per class. There might be a strong business reasons for doing that. I read somewhere about network printer as one such good example which immediately connects our human brain to a as a Singleton. Think about it, we have a network and we have one network printer. Everyone shares it but the printer has one instance available for all which is used by all. For printing. There is another example, a TV channel. One TV channel like ESPN is watched by many folks. It's one channel existing by itself, as a singleton. There might be many more business cases where we might need a singleton.


Creating a Singleton

Creation of a Singleton can be done with the help of a method which is a bit special kind of method. Generally creation of objects in Java is closely associated with a constructor. Every time you use a new method the constructor is invoked and the object is created. This is exactly we want to avoid when it comes to Singletons since we don't want to create the objects again and again. What do we want to do ? We want to create a Singleton but just once. In order to achieve that we do typically do two things ­ 

1) We write a method which will be responsible for creating a singleton only once. Then the methods responsibility shifts a bit and it keeps checking if the object is already created and if it is then the method needs to pass the same object back to the caller.

2) What about the constructor ? Make it hidden by making it private or protected.





If you are reading these series then you would know that we have used an OMX example for explaining the Abstract Factory. Let's revisit that example as it needs a Singleton. Let's first see the class diagram for our use case.


If you look at the use case described above you would see that CalcTax is something that the client needs, over and over again. Sometimes you might want to calculate tax for EU use case and sometimes for Asian use case. That does not probably mean that you have to keep creating CalcTax object every time. But where will we have the method that we just spoke about which would create the Singletons ? At CalcTax level ? No. CalcTax in most probability would be an Abstract class or an Interface. So the method which would eventually be responsible for creating singletons would be at the sub­classes (EUTax or AsiaTax) level. So let's look at some code now.



And a sample sub­class where the action is !




So which method is the special method here ? It is getInstance which is marked in bold. You can easily see why. It creates the object but before that checks if the object is already existing. If it does it just returns the previously created object. Another thing to notice. The constructor here is marked as private for good reasons.


Now let's see a client that is accessing these classes.



When you run this client the output is something like shown below 


Creating the EU object for the first time

Tax Calculation for Europe Use Case

Tax Calculation for Europe Use Case


Creating Asian object for the first time

Tax Calculation for Asia Use Case


Tax Calculation for Asia Use Case



This clearly shows that the objects were catered once and used many times. In the code if you have noticed we also have a commented section.



If you uncomment it your IDE will catch it and complain about the constructor not being visible. That's what we want, isn't it ? We want the clients to NOT create objects using the the constructor. We have getInstance for the same which creates the Singletons for us !But what happens when singletons are accessed in a multi­threaded enviorment ? More on it later.

cheers !



Views: 346

Comments are closed for this blog post

© 2015   Created by Rohit Pant.

Badges  |  Report an Issue  |  Terms of Service