This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
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
Joined: Jan 05, 2006
my intimation is in realtime scenario the DAO,BO,SessionBean,BD where they returns singleton instance
Joined: Aug 27, 2004
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..
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 ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
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.