• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

SingleTon Class

 
Ranch Hand
Posts: 303
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi,

When we should use singleton class in our project.

if any example then please tell to me.

Thanks
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Short answer: very, very, very seldom - so seldom that "never in my project" is a good enough bet.
 
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Suppose you are doing a project on entering the employee details into the database..

You have to enter a list of 100 employees...that means you have to create 100 objects using a loop or whatever logic is possible..

Instead you can use Single Ton concept to create only one object and use it to enter the list of 100 employees...
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

roshan jose wrote:Suppose you are doing a project on entering the employee details into the database..

You have to enter a list of 100 employees...that means you have to create 100 objects using a loop or whatever logic is possible..

Instead you can use Single Ton concept to create only one object and use it to enter the list of 100 employees...



Why would you want to only create one object? And if so, why wouldn't you just create one object just before the loop?
 
roshan jose
Greenhorn
Posts: 27
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
i have not much idea about this

Just yesterday I came to know about it in our .NET workshop conducted by our college.

So the resource person told us that this concept can be used to create static objects and so you dont have to waste memory space by creating many objects.

by just creating one static object you can enter all the employee details as i have said in my above post
 
Ranch Hand
Posts: 2458
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Exactly. Just create one object at the right place and the right moment.

The need for a singleton just indicate in almost all cases a flaw somewhere in the code design.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

roshan jose wrote:
So the resource person told us that this concept can be used to create static objects and so you dont have to waste memory space by creating many objects.

by just creating one static object you can enter all the employee details as i have said in my above post



Just creating a new object per loop wouldn't waste any memory, either, because at the beginning of each iteration, all previous objects presumably would be eligible for garbage collection. And short lived objects are very easy to garbage collect.

In general, memory is *cheap*, compared to writing code. So, typically it pays off to care for easy to understand, well maintainable and extensible code first. Using programming tricks to save memory only makes sense in very specific cases.
 
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In general, a singleton is used for shared resources.
Imagine a scenario where you got lots of classes, who are trying to piggy back on the desktop configuration settings. You know stuff like font and colors and size.

Since the desktop is a common factor, it would be a good design to have a common class which would give you access to all these attributes.

Check this out for more detailed stuff
http://www.javacamp.org/designPattern/
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh Godbole wrote:In general, a singleton is used for shared resources.
Imagine a scenario where you got lots of classes, who are trying to piggy back on the desktop configuration settings. You know stuff like font and colors and size.

Since the desktop is a common factor, it would be a good design to have a common class which would give you access to all these attributes.



This is a perfect example of why a Singleton, even if it sounds attractive at first sight, because it's so easy to get at the stuff you need, can really hurt you later.

Just imagine that the above system suddenly needs to run on a dual monitor system, where you in fact can have *two* desktops. If you used a singleton before, you will suddenly have to change classes in the whole system to allow for more than one desktop.

It's really a *bad* idea to spread the knowledge that there is only one instance of a class through the whole system. It's exactly what decoupling is *not* about.
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Ok.
My bad. I did not consider the multiple desktop scenario.
How about a properties manager? Common properties being shared across classes?
Or DBManager where you want one SPOC for all DB related transactions?
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh Godbole wrote:Ok.
My bad. I did not consider the multiple desktop scenario.
How about a properties manager? Common properties being shared across classes?
Or DBManager where you want one SPOC for all DB related transactions?



I would always rather use a Just Create One instead. The global access point of the Singleton pattern just creates too much trouble. See http://butunclebob.com/ArticleS.UncleBob.SingletonVsJustCreateOne
 
Maneesh Godbole
Bartender
Posts: 11497
19
Android Google Web Toolkit Mac Eclipse IDE Ubuntu Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Interesting article there. Thanks. Made me think on lines I had not considered before. Thanks.

I can see the benefits of not using a singleton (especially for unit testing scenario). But I do not understand what is going to guarantee the existence of only one instance?

One small point. "JustCreateOne" is kind of misleading. My first impression was, when you want it, just create one. I think "CreateOnlyOne" would be more apt.
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

Maneesh Godbole wrote:But I do not understand what is going to guarantee the existence of only one instance?



Nothing. But how do you know that you want to have exactly one instance until the end of all time, anyway. I don't think you can know that. You have to rely on the professionality and competence of those who are using it - whether you are using the Singleton pattern or not.

Good point about the name. I guess it's an artifact of it being a counterreaction to the Singleton pattern (like in "don't use the Singleton pattern, just create *one* object").
 
reply
    Bookmark Topic Watch Topic
  • New Topic