We aren't allowed to create a instance directly because the constructor is private or protected so we have to use a public static method to get the instance.
SCJA 1.0, SCJP 1.4, SCWCD 1.4, SCBCD 1.3, SCJP 5.0, SCEA 5, SCBCD 5; OCUP - Fundamental, Intermediate and Advanced; IBM Certified Solution Designer - OOAD, vUML 2; SpringSource Certified Spring Professional
If you make the constructor private only the class itself can create an instance of this class via the "new" keyword. Therefore you need a way to trigger this creation from outside the class. And if you don't yet have an instance (= object) of the class you can only use static methods because they can be invoked on the class itself and don't need an object instance. Hope that makes it clearer
If you consider the above example you will get an idea as to why we need a static method in a singleton class. As to the reason of why we need a singleton class let us consider a project with database connection(web project)... It is better design to have one connection open to the database and all the user requests to be processed through that connection. This can be achieved by using singleton class because it makes sure that only one object is created thereby providing a single thread(not in java sense) to the database.
As to the post that singleton is considered a bad practice no comments
The general idea of a singleton is not bad at all. But the example above quickly shows some practical problems. The database example is indeed a typical singleton demonstration. The problem is that it's very likely that multiple database connections are needed in a multithreaded context (i.e. a servlet based web application) and this is exactly that type of application where the classic singleton pattern doesn't work as expected because it's not thread-safe and therefore it's very likely that there will be MORE than one instance of this class But there are (complicated) attempts, too, which make it really thread-safe although there are more incorrect examples which only try to make it thread-safe.
But the bigger problem is that this static creation method easily allows to hide the fact that you have created a global variable because you can access the singleton from everywhere in the application without explicitly declaring a dependency on that singleton class (you have it implicitly with the static method). And THAT is one of the main problems of the singleton pattern. You'll find lots of discussions here on JavaRanch or just Google for it
If you really need the concept of a singleton than there are better ways to handle resource management for example. They will save you a lot of trouble.
As to the post that singleton is considered a bad practice no comments
What do you mean with this? Do you think it is NOT bad design? Ever worked with a big application which makes heavily use of such so-called singeltons? Or tried to make an application testable which consists of lots of those singeltons? Just curious why you said "no comments".
Marco
Salil Vverma
Ranch Hand
Joined: Sep 06, 2009
Posts: 219
posted
0
Hi Marco,
I agree with that the above code might give a chance of multiple object creation in a multiple threaded environment. We can prevent this by keeping the following section in a synchronized block but this would create an performance overhead.
If you really need the concept of a singleton than there are better ways to handle resource management for example. They will save you a lot of trouble.
Could you please suggest what can be an alternate way to implement the singleton concept ?
We can prevent this by keeping the following section in a synchronized block but this would create an performance overhead.
In fact there are alternative ways to using "synchronized" but lots of them are just too complicated for practical usage if you're not very familiar with concurrency on top of Java and the JVM. A big problem is, that it's often difficult to even know if you got it right when it comes to concurrency. Anyway, Brian Goetz gives lots of very good examples in his book "Java concurrency in practice".
Could you please suggest what can be an alternate way to implement the singleton concept ?
For example there are well known frameworks for dependency injection which can not only inject dependencies into another object but also manage the lifecycle of objects, i.e. the frameworks are also capable of taking care that only one instance of a particular class will be created which is then shared between all objects which depend on it. If you're building an enterprise or web application with JEE 6 for example you can benefit from singleton concepts already built into the platform.
If you need a singleton just to control access to limited resources like database connections there are often ready made opensource solutions you can use for resource pooling. These solutions are mostly more powerful and feature rich than a naive singleton implementation could be. Here again, if you're working with an enterprise or web application you typically can rely on the application server or servlet container to manage resources like database or mail server connections for you.
That said, I don't want to tell everybody here that you should never use a singleton under all circumstances. There are surely situations when a simple singleton is just good enough. You should just be aware of the negative effects the singleton pattern can have!
singletons semantics have their place (e.g. inside ioc-containers you often have instances which are immutable and only one instance is necessary and available).
the danger is if you have mutable state singletons. they tend to end in hidden global variables in your app. then if problems occurs analyzation is very tricky and debugging is hell, especially in multithreaded scenarios.
mutable state singletons are an enemy for encapsulation and reasoning about side-effects of code-statements!
Kengkaj Sathianpantarit wrote:We aren't allowed to create a instance directly because the constructor is private or protected so we have to use a public static method to get the instance.
And also you can easily attack the private constructor with Reflection,that's why we have declared a static method which generally responsible to return same object reference(All calls to Singleton.getInstance())
I agree. Here's the link: http://ej-technologies/jprofiler - if it wasn't for jprofiler, we would need to
run our stuff on 16 servers instead of 3.
0
