[Logo]
Forums Register Login
Singleton design pattern
Hi Everyone,

I know what a singleton pattern is and i also know that logging is an example of Singleton. Can somebody help me identifying scenario(s) where singleton can be proved as a cherry on a cake. I am looking for some real time, project specific scenario examples where we can use singleton design pattern. Assume that i am working on a banking (Le'ts say RBS) or telecom project (bharti airtel).
Suppose you have a static table in a database, meaning that you won't change it while execution and only retrieval operations will be performed on it. One example of this table may be the one which stores the list of countries and corresponding country code and time zone. To improve the performance you will want to implement cache. Since the data of this cache won't be changing anytime you can implement this cache as a singleton class.  Because there is no need of different instances of this class as all of them will have same state or same data. Having singleton here improves memory consumption and prevents memory leaks but to only a limited extent
The singleton pattern is never a cherry on a cake. You must always avoid it. When objects pull information from thin air (globally accessible data), the application becomes very rigid, and improving it with new features will invariably lead to buggy, untestable spaghetti code.

The scenario that Mishra describes is better solved by injecting a repository of countries into whatever method or constructor needs it. It should implement an interface, so that you can write another implementation wraps around an actual repository, and performs caching. It's even better to let your application container framework handle caching though.
Agreed. It's true that having a single instance of a class is a good thing, in terms of memory consumption and consistency of data, but it should be enough to just create one instance of the class and pass it around to methods which need it.
I agree too, it is not actually advisable to have a rigid singleton in a project, I merely described a scenario where singleton may be useful.
In my opinion, in a major project following strategy design is better whether it is implemented by you or done emphasized by a framework you use
I would like to add one more thing, that is in my opinion, defining singleton is better when we are developing an api that other developers will talk to instead of providing an application directly. In that case i say my example will hold too
I don't understand your description of the scenario in your last post. Can you elaborate, or explain with a small example?
 

Stephan van Hulst wrote:I don't understand your description of the scenario in your last post. Can you elaborate, or explain with a small example?


yeah sure, I will try my best to elaborate if I am not able to do it correctly do inform me.
Let us assume that we are developing an API that has some arbitrary target and function. Let's call this API "McRitchie"
We don't need to look at McRitchie as a whole, rather than just a small part. One particular functionality that McRitchie is trying to implement is caching databases. In the cache, the basic implementation can be something like a nested Hashmap that holds the records of the table.
One assumption that we are making is that the table we want to cache is static or shall I put it like "Only static table can be cached by McRitchie"
If it were an application being developed we could have made an object of the cache ourselves and passed it around to whatever part of the application needing it. But since we are making an API we have to consider that rather than us populating the cache we will have our user (some other programmer) do that by using our API. Now, we have already assumed that the tables going to be cached are static (they won't be updated or modified). Since the tables are static, it would be really unnecessary to be able to create multiple objects of a cache that won't be changing in the runtime once loaded. But how can we guarantee such behaviour, can we guarantee that our user in all cases will only create at most one object (We can't, refer to einstein's quote about human stupidity and universe to get an idea ),  to achieve the one object per runtime of a static cache we can implement the cache class as singleton.
That's all.
If I was able to explain well give me a thumbs up, otherwise please be a positive critique and provide me with some of your expert insight.
Thanks
I don't understand what a "static table" is.

Oh wait a minute, you're talking about a table that can't be changed. "Static" isn't a good word there since it makes me think you're talking about static variables, which means you would be confusing objects and variables. Sorry about that.

But I don't see why the immutability of a table is important for this. On the contrary, if the table were mutable it would be much more important to make sure there was only one instance of the table being used.
Your example also doesn't address the main question, which was why is the singleton design pattern superior to just creating a single object?

Singleton pattern is a design solution where an application wants to have one and only one instance of any class, in all possible scenarios without any exceptional condition. It has been debated long enough in java community regarding possible approaches to make any class singleton.
The obvious solution to "I only want one instance of a class" is to only make one instance of a class. There is absolutely no need for the singleton pattern.
. . . and for the last thirteen years, the best way to have one instance has been like this:-
I understand. Thank you everyone for pointing out some obvious error in my concepts. I learned and found out that yes you guys are right.
I tried to answer the OP's question but maybe I deviated. I will ofcourse learn to answer better by keeping at it.
This community is so good and helping. You guys are great always ready to help and offer positive criticism which ofcourse is one of the key things missing from my environment here.
Thanks again
(1 like)
 

Mishra Saurabh wrote:. . . This community is so good and helping. . . . .

Gee shucks! You gert us all 'mbarrassed!

Thanks again

That's a pleasure
 

Campbell Ritchie wrote:. . . and for the last thirteen years, the best way to have one instance has been like this:


Only if that instance is a constant. It is most definitely NOT the best way for instances of a mutable type.
Good point.
Hi Saurabh

Real life example of Singleton example : Reading Application.properties file using Singleton Instance

I usually say the same in an Interview 
Yes santosh, that is a correct example.
I have done some research and your example was on it. It had other examples like, the DAO classes, the logger classes, etc
What are you going to do if you want to change the application properties programmatically, while running? Surely you're not going to modify the global instance, are you? And how are you going to unit test classes whose behavior depends on application settings?

Application settings are NOT a good example.
 

Stephan van Hulst wrote:What are you going to do if you want to change the application properties programmatically, while running? Surely you're not going to modify the global instance, are you? And how are you going to unit test classes whose behavior depends on application settings?

Application settings are NOT a good example.




Hi

Using a program we would not intend to change value of Application Properties file
This option just makes Interviewer mouth keep shut on further questions 
Wink, wink, nudge, nudge, say no more ... https://richsoil.com/cards


This thread has been viewed 265 times.

All times above are in ranch (not your local) time.
The current ranch time is
Feb 23, 2018 21:18:22.