Singleton Pattern Vs All Static Methods

[Suresh Bansal]

Hello Friends,
Consider this scenario.
1. All the methods in a class are static.
2. We use singleton pattern.
I beleive that in both the cases we achive the same result, that is only one instance of the class.
While i think its better to use case 1, but case 2 is a very popular design pattern. The reasoning is that both achieve the same result, but in case 2 one has to do a extra getInstance() first and then one can call the functions.
Please, share your views. What do you think.
Suresh Bansal

[Matts Smith]

I agree case 1 is better most of the times. The only reason I would use case 2 is when my object has to implement an interface.

[Wilfried LAURENT]

Moderator, this thread already exists in Java Beginner. Close it here or there.
W.

[Suresh Bansal]

I may not be fully familiar with the rules.
But if a topic concerns more than one forum, then is it not okay for the topic to be in both the forums ?

[Matts Smith]

Originally posted by Wilfried LAURENT:
It depends on what you want to achieve.
With the singleton implementation, you can hide the real implementation of your service. The client only knows the contract (API) but does not know about the implementation. This is easily configurable with a bridge or a property file.
You can not do that with a 'static method' implementation.
W.

I might miss the point but what is so hard to do with static methods? And what's that service part about? Please elaborate.

[Suresh Bansal]

--------------------------------------------------------------
A Singleton design would guarantee just one instance of the class.
A class with only static methods could be instantiated many times (pointless I admit, but possible all the same).
--------------------------------------------------------------
I agree with you ...
I think then that its best to merge the two things.
We can have all static methods and a private constructor with no getInstance() method. That way instances of the class cannot be created.
Just like the Math class is implemented in java.

[Ilja Preuss]

The point of the singleton pattern ist to hide the detail that there is only one instance. In fact, getInstance() could give you a new instance each call, or alternate between two instances or... Also, using the singleton pattern you can still use polymorphism, that is getInstance() could give you an instance of an other (sub-)class (depending on some configuration, for example).
Therefore, an all-static class is not a substitute for a singleton!

[Matts Smith]

Originally posted by Ilja Preuss:
The point of the singleton pattern ist to hide the detail that there is only one instance.

fine so far. Static = no instance at all which is even better when you think about it.

In fact, getInstance() could give you a new instance each call, or alternate between two instances or...

I would not call it a singleton anymore. this is an instance pool. The subject at hand is singleton.

Also, using the singleton pattern you can still use polymorphism, that is getInstance() could give you an instance of an other (sub-)class (depending on some configuration, for example).

maybe I wasn't clear enough but when I talked about implementing an interface I kind of accepted that anything that had to do with inheritance has to be implemented as a singleton. Also don't forget that a singleton constructor is private so inheritance from the singleton is not possible. Gotcha there right?

Therefore, an all-static class is not a substitute for a singleton![/B]

My bottom line is that all static methods is a good substitute for singletons. less code, easier to understand. Look at the JDK. How many singleton do you see compared to all static classes?
off hand I see Runtime. I might be wrong but I guess java.lang classes can't be loaded twice which would not be the case with user's classes. Anyone can give a confirmation on this?

[Alan Shalloway]

Matts said: "Also don't forget that a singleton constructor is private so inheritance from the singleton is not possible. Gotcha there right? "
Actually, the essence of a singleton is controlling the construction of the object. protected will work just fine for that so inheritance will work.
Singleton should be used when static methods won't - since static methods are easier.
Instead of asking which is better, ask what can one do that the other can't and do I need to do that?
Singleton can be modfied to allow for more than one instance, so if that's going to happen, you might want to start with using getinstance so you don't have to change it later. Also, with singleton, since you can get inheritance, if you need that, you should use it. If all you need is one instance of something and and static methods work - use them - it's simpler.
There is one other case I can think of, using a singleton can potentially control the order of when the object is instantiated better. With static methods, the static members will be instantiated the first time the class is referred to. This may be a reference to some const in the class. In the singleton pattern, it won't be instantiated until the getinstance is called.
------------------
Alan Shalloway.
Look for Jim Trott and my book: Design Patterns Explained
Visit our site Net Objectives.
Visit our Design Patterns Explained Community of Practice
Check out our CDROM based audio training in XML

[ersin eser]

Thanks for the answer Mr. Shalloway .

[Ilja Preuss]

Static = no instance at all which is even better when you think about it.

It thought about it, but I don't see how no instance would be inherently better than one.

---------------
In fact, getInstance() could give you a new instance each call, or alternate between two instances or...
---------------

I would not call it a singleton anymore. this is an instance pool. The subject at hand is singleton.

But the clients don't care! You could easily change between instance pool and singleton without any change in a client!
Again, this is one of the benefits of the singleton pattern: The number of actual instances is hidden from the client code.

My bottom line is that all static methods is a good substitute for singletons. less code, easier to understand.

And often harder to maintain, because of less encapsulation.

Look at the JDK. How many singleton do you see compared to all static classes?

That seems to be the wrong question to me. The more interesting question is: When do you see all static classes, when singletons?
I see all static classes like java.lang.Math and java.util.Collections. These classes provide a bunch of utility methods and they don't seem to hold any state.
On the other hand, classes representing resources like java.lang.Runtime and java.awt.Toolkit are implemented as singletons.
But in the end this doesn't mean much - sadly the java libraries aren't always an example of good OOD. Just take a look at the Date/Calendar classes or the GridBagLayout - and frighten...

[Matts Smith]

Originally posted by Alan Shalloway:
Actually, the essence of a singleton is controlling the construction of the object. protected will work just fine for that so inheritance will work.

quote from design patterns in java volume 1 by Mark Grand page 129.

To enforce the nature of a singleton class, you must code the class in a way that prevents other classes from directly creating instances of the class. The way to accomplish this is to declare all of the class' constructors private.

There is one other case I can think of, using a singleton can potentially control the order of when the object is instantiated better. With static methods, the static members will be instantiated the first time the class is referred to. This may be a reference to some const in the class. In the singleton pattern, it won't be instantiated until the getinstance is called.

getInstance is static. same as any other static method. please refer to JLS 5.3 if you would like to understand how and when classes are loaded. Unless what you meant is that your singleton implemented an interface (did I say to do it as a singleton?) and use the interface to access a singleton, which would be "gotten" in another class. Then again the load ordering differences would be minimal. And if you depend on that you know you're in trouble.

[Matts Smith]

And often harder to maintain, because of less encapsulation.

I don't get it. Why would it be less encapsulated if it's static?

Originally posted by Ilja Preuss:
That seems to be the wrong question to me. The more interesting question is: When do you see all static classes, when singletons?

you got a point there. Requirements drive software.

[Matts Smith]

Sorry
I did not mean JLS 5.3 but JVM 5.3 http://java.sun.com/docs/books/vmspec/2nd-edition/html/ConstantPool.doc.html#72007

[Michael Fitzmaurice]

There is also the danger that static methods lead to procedural type programming when abused. Have a look at these answers to the singleton Vs static methods choice:

http://www.javaworld.com/javaworld/javaqa/2000-12/03-qa-1221-singleton.html
http://www.javaworld.com/javaworld/javaqa/2001-05/01-qa-0504-oo.html?
Michael
------------------
"One good thing about music - when it hits, you feel no pain"
Bob Marley
[This message has been edited by Michael Fitzmaurice (edited December 14, 2001).]

[Matts Smith]

From the 2nd article

protected ChildTraceClass() {} // do not allow instantiation

need I say more? cough cough

[Suresh Bansal]

Thanks Matt, Alan Shalloway for your views ...
This has helped clear up issue of static vs singleton.
Now its clear that its the question of when one should be used over the other depending on the requirements like said by Ilja Preuss.
While static inplementation is easier and should be used if relevant, singleton pattern allows us more control.

[Ilja Preuss]

Originally posted by Matts Smith:
----
And often harder to maintain, because of less encapsulation.
----
I don't get it. Why would it be less encapsulated if it's static?

You may see the number of allowed instances as an implementation detail. You may see the actual implementation used as an implementation detail. These both are encapsulated and hidden by the singleton pattern, but not by the all static class. (As I think about it, possibly encapsulation is the wrong term for this? It's hiding of implementation specific details.)

[This message has been edited by Ilja Preuss (edited December 15, 2001).]
[This message has been edited by Ilja Preuss (edited December 15, 2001).]