This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes singleton designpattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "singleton designpattern" Watch "singleton designpattern" New topic
Author

singleton designpattern

sai prasanna
Ranch Hand

Joined: May 02, 2005
Posts: 167
hi all
This is an example of singleton design pattern

public class ClassicSingleton {
private static ClassicSingleton instance = null;

protected ClassicSingleton() {
// Exists only to defeat instantiation.
}
public static ClassicSingleton getInstance() {
if(instance == null) {
instance = new ClassicSingleton();
}
return instance;
}
}
The ClassicSingleton class maintains a static reference to the lone singleton instance and returns that reference from the static getInstance() method.
what does static reference mean?

thanks in advance
saiprasanna
Arnold Reuser
Ranch Hand

Joined: Nov 20, 2003
Posts: 196
You've implemented the behaviour that each JVM will instantiate only
one intance of a certain class.As a result "static" refers to the JVM.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Static means a variable or method is associated with the Class rather than an object instance of the class. Since the class is only loaded once (per class loader) regardless of how many instances you make, static variables only exist once and all references to the variable really refer to the thing.

So, your static variable refering to an instance of the class holds only one instance from the time it is loaded until we shut down the JVM. That happens to be exactly the definition of "singleton" so it's a perfect place to keep a singleton.

It would be a good idea to make your getInstance() method thread safe. You can synchronize the whole method or initialize the variable with an instance in the first place and skip the null check.

Singletons have a few issues that can lead to trouble in the long run. If nothing else, they take us back to the bad old days of "global" variables. Always ask yourself if a singleton is necessary. What kind of singleton are you thinking of making now? Or are you just checking out your understanding of the pattern?


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
Vishnu Prakash
Ranch Hand

Joined: Nov 15, 2004
Posts: 1026

If nothing else, they take us back to the bad old days of "global" variables.


By "global" variables are you refering to the


private static ClassicSingleton instance = null;


declaration of static reference of the singleton class. Why will this lead to issues in long run. Doesn't the static reference has a private access.


Servlet Spec 2.4/ Jsp Spec 2.0/ JSTL Spec 1.1 - JSTL Tag Documentation
Frank Carver
Sheriff

Joined: Jan 07, 1999
Posts: 6920
By "global variables", Stan is referring to the once-popular practice of not using method-local or object-local variables at all. A traditional "global variable" is not associated with any particular class, module, object, package or whatever. It just exists, and is readable (and usually writable) by any code in the system. In many early programming languages all variables were "global" by default.

As I hope you can understand, this approach can be a breeding ground for hard-to-test bugs.

Java (and object-oriented languages is general) makes it relatively easy to use local variables instead, so the use of anything which acts like a global variable (public static fields, Singletons, etc.) is generally discouraged.


Read about me at frankcarver.me ~ Raspberry Alpha Omega ~ Frank's Punchbarrel Blog
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Originally posted by Vishnu Prakash:
Why will this lead to issues in long run.

Singletons have a detrimental impact on horizontal scalability.
Even if you factor them out to create a remote/distributed component/application/service to be shared by many instances of the same application you are potentially creating a bottleneck.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Singleton within a cluster is indeed a tricky thing to build. If requirements allow, I'd recommend a database instead. DB vendors are pretty good at concurrent access.

A singleton within a JVM is pretty handy sometimes. I use them for caches and pools and such. Knowingly stepping right in a big steaming pile of global, because I trust myself to not misuse it. I'm sure you've heard that before.

The global issue is as described above. Any object loaded by the same classloader can say

GlobalThing global = GlobalThing.getInstance();

That means any notion of protecting data is gone - any notion of enforcing who is responsible or allowed to see it, change it, etc. If I set a value there I don't know what method or thread might change it while I'm not looking. I worked on enough 25,000 line COBOL programs to know some of the bad places this can go!
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
Another issue with singletons is that they lead to a rather tight coupling. Every class that calls the getInstance method is coupled to the fact that there is exactly one instance. Imagine the changes you have to make if after some time you find out that you now need two different instances.

I typically prefer the Just Create One pattern.
[ May 03, 2006: Message edited by: Ilja Preuss ]

The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Imagine the changes you have to make if after some time you find out that you now need two different instances.


Sometimes it's as simple as changing the getInstance() method. We migrated a singleton from a desktop application to server code and was naturally a threading disaster. It was easy to change it from "return theInstance" to "return new Instance()".

Of course it's not always that simple. We were lucky that the only reason somebody made a Singleton was to reduce object creation overhead. (Premature optimization incarnate.) It's easy to imagine situations that would not be so simple.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
One example is when start writing unit tests and suddenly feel the need to mock the singleton...

Which reminds me of this post: http://www.developertesting.com/archives/month200604/20060430-MockingASingleton.html
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
There's nothing to stop us from doing Singleton well. Make it an interface, make a robust factory method or even an abstract factory, glue it up with dependency injection, build as many implementations as you like. We usually do them quick & dirty with all the associated costs, but the getInstance() method provides an opportunity to do much better things, even late in the project.

Hmmm, my Wiki has a singleton DataStore with an interface, factory class, abstract base class and concrete in-memory, file-system and mock implementations. Guess I did at least one thing kinda right.
[ May 05, 2006: Message edited by: Stan James ]
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
True, you can do that. I still prefer to inject mock objects directly by passing it to the object under test, instead of having it get it by calling a static method. The latter still feels much more brittle to me...
Don Kiddick
Ranch Hand

Joined: Dec 12, 2002
Posts: 580
I've been using a ServiceLocator pattern with some success for 'global' objects such as these. One advantage of this particular brand of global access point is that it is easily mockable. Also it has a name which is useful for communication and makes you sound clever...

I think in an ideal World we would always inject our dependencies. But sometimes it can make the code simpler to make an object 'global'. Use in moderation!

D.
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: singleton designpattern