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 have a question regarding Singleton pattern in my mind.
It is generally told not to use Singleton pattern in distributed architecture. Because it may be one per JVM, one per classloader etc. So the singleton nature is destroyed.
But a popular framework like Spring is using Singleton as its default scope. So how is it managing the Singleton nature of a class around the application in a distributed environment?
Can somebody explain me?
Singleton as a concept is not a problem. It is just a "one object of this class" idiom. That happens quite often... in fact so often that it is the standard scope for Spring.
What is bad is implementing it at language level (e.g. a constant holding an instance) because then you loose testibility, possibility to inject, it is hard to refactor and so on. All what is bad about the Singleton.
This is not true when managed by Spring. If you need another instance you just create it. Singleton in Spring does not enforce only one object of a class. It just means that the instance created is shared (and not like with the prototype scope every caller gets a new object).
When done at the language level this means you need to e.g. create a new constant, rewrite access, change dependent objects, think about thread safety...
So having "just one object of a class" is not a problem. Enforcing it on low-level is.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com