• 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

 
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
hi i know that a Singleton class consists of only one instance. The thing is
I want to know where it is useful in real time applications.
 
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I think question is in wrong forum first of all.......


Singletone class is useful when, you want to have a single instance of a class in application
e.g. If in a distributed scenario i want to parse an XML only once & want to read the data only once (so that subsequent requests use same info instaed of parsing XML each time).i will go for singletone pattern

Correct me if i am wrong...
Shrinivas
 
prasad naga
Greenhorn
Posts: 10
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
my intimation is in realtime scenario the DAO,BO,SessionBean,BD where they returns singleton instance
 
Shrinivas Mujumdar
Ranch Hand
Posts: 328
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Yes true for DAO,BO but not true for Session Beans as Stateless session bean are pooled.Stateful session bean only single instance is created per client but you will not call them Singletone i suppose..


Shrinivas
 
Rancher
Posts: 13459
Android Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Moving to Java in General (intermediate).

Dave
 
Greenhorn
Posts: 16
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
singleton pattern is used when u need to have a single instance of the class in whole application, i.e. class is instanciated only once during the lifecycle of the application.

This pattern is useful with connection objects, XML data, which remain constant during the whole application and need not be instanciated again and again.
corrent me if I am wrong
 
Ranch Hand
Posts: 148
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
In real scenario Singleton pattern is used in cases where you need to ensure a single instance running.

Ex. In an Application server single instance of

> Threadpool

> Database connection pool

> Object pooling

> Memory cache

That should give you fair idea on this pattern

 
Ranch Hand
Posts: 388
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
be careful with singleton pattern.
i consider it an evil-bad-anti-dont-use-no-go-pattern.


search the web for why singletn is evil...

k
 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Singleton is overused and abused (I hear) but there are situations where it works just fine. Some of the criticisms like these really criticize implementation details commonly found in Singleton examples.

For example to that posting's SRP complaint: a Singleton class need not control its own creation. To the coupling complaint: you can have an abstract Singleton with different implementations. GoF devotes a page or so to these ideas.

The "global" complaint is true. If you use a Singleton to hold state that any method in the system can read and write you're just writing COBOL in Java. Don't do it.

The "long lasting state" is true, too. A Singleton cache is a great place to put things and never remove them, also known as a memory leak. If your state is causing testing problems like he describes, you're abusing globals again.

Be careful. Some of these tools are sharp. But don't throw them away.
[ January 12, 2006: Message edited by: Stan James ]
 
Greenhorn
Posts: 19
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Also, most of the limits of singletons tend to disappear when you use a framework like Spring. Essentially, all beans created by Spring are singletons as per the default behaviour.
However (going through http://blogs.msdn.com/scottdensmore/archive/2004/05/25/140827.aspx) :
1) Spring takes care of the glue. If you want to know what singletons a class uses, you just have to look at the XML wiring or the setters of that class. Also, you don't have to deal directly with global variables - they're being pushed onto you by Spring.
2) Using Spring, a class does not need to know it is a singleton. All it has to do is make sure it is stateless and thread-safe.
3) You don't have to be tightly coupled if you use interfaces. Your singleton implements an interface. And all its clients talk to that interface. Then, it's very easy to plug different implementations through bean wiring.
4) That's indeed a limitation, but that's also the main feature of singletons - it's actually why they exist at all. It's a very important feature when setup is heavy. For instance, I have beans which (indirectly) query a database, read and parse half a dozen XML files and makes a few Internet connections as part of their setup. Doing that every single time I need a bean like this would be crazy. Likewise, it would be close to impossible to implement application-wide caching of anything without some form of singleton.

Actually, I think that singletons + IoC pattern can be the real backbone of an application. With it, designing service or DAO patterns is very easy. You can very easily plug in real implementations, mock implementations or alternative implementations.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic