Singleton vs Static class

[aakash bhatt]

Why do we need to make a class singleton when we can achieve the same by declaring attributes and methods as static.
When searched i found the benefits are:
1) Lazy loading of resources in singleton class.
This seems to be fine.

2) Inheritance
While i didn't still got cleared with inheritance as when i extends the inherited class the getInstance() method in base singleton class
is static, as it is static I cannot override it. So what do we achive by inheriting it. Is there any more advantages.

Apart from the above 2 point are there any more advantages

Thanks,
aakash

[Max Habibi]

I generally use a static class.

[Rovas Kram]

Please excuse my ignorance but aren't you comparing a design pattern with one particular implementation detail? I mean aren't you just using a static class to implement the Singleton pattern? Or what do you mean by Singleton?

[Peter den Haan]

Originally posted by aakash bhatt:
Why do we need to make a class singleton when we can achieve the same by declaring attributes and methods as static.

That's not a Singleton - that's a bunch of global functions. Global functions have their legitimate place, but that's few and far between.

One of the problems with the Singleton pattern is that it's often the Singleton anti-pattern; a quasi-object-oriented way to create global variables or to stick global functions that are necessary because the object model is flawed. Singletons can be a code smell. Badly implemented Singletons with zero pluggability, zero testability, and zero agility are certainly a code smell.

When you want to create a singleton, ask yourself what you're trying to achieve. Is there a fundamental reason why there can only be one instance of this class, or do I just happen to need only one right now? Do I want to impose a constraint, or am I only looking for a convenient place to get a reference to this object, turning the Singleton into no more than a global variable? Does this object perhaps have a 1:1 relationship with another object in the system, of which I currently happen to need only one copy? Or does this class perhaps have a 1:n relationship with a set of objects which really ask for a containing parent? Singletons are used in all these situations, and in many there's a better solution around. "Better" as in: more expressive of the relationships between classes and objects. More faithful to the problem domain. Fewer artifical constraints that impede testing, enhancement and re-use. Less work.

2) Inheritance
While i didn't still got cleared with inheritance as when i extends the inherited class the getInstance() method in base singleton class
is static, as it is static I cannot override it.

That's the classic simple-minded Java Singleton pattern. In fact, it's a horrible way to implement it; as you note, it's difficult to get much mileage out of inheritance; there's no good opportunity for pluggability, testing is difficult where the Singleton is a collaborator that you want to stub, and so on. Fortunately that is by no means the only way to implement it. For example, you can make the Singleton class configurable and use Class.forName() to instantiate your Singleton in the (static) factory method. The next step could be to give responsibility for instantiating and managing the Singleton to a separate factory class. Take that idea further and you get the Abstract Factory pattern or a repository. Take that further still and you end up with something like the Spring bean factory. Which is how I create most of my Singletons these days.

Apart from the above 2 point are there any more advantages

The Gang of Four list the following.

Controlled access to sole instance. [...]

Reduced name space. [...]

Permits refinement of operations and representation [ie subclassing - PdH]. [...]

Permits a variable number of instances. The pattern makes it easy to change your mind and allow more than one instance of the Singleton class.

More flexible than class operations [which] make it hard to change a design to allow more than one instance of a class. Moreover, static member functions in C++ [and Java - PdH] are never virtual, so subclasses can't override them polymorphically.

- Peter
[ August 11, 2004: Message edited by: Peter den Haan ]

[santhana Marimuthu]

1.Singleton represent object and Static class represent a method.

2. Static class provides better performance than Singleton pattern, because static methods are bonded on compile time.

3. One more difference between Singleton and static is, ability to override. Since static methods in Java cannot be overridden, they leads to inflexibility. On the other hand, you can override methods defined in Singleton class by extending it.

4. Static classes are hard to mock and consequently hard to test than Singletons, which are pretty easy to mock and thus easy to test. It’s easier to write JUnit test for Singleton than static classes, because you can pass mock object whenever Singleton is expected, e.g. into constructor or as method arguments.

[Jeff Verdegan]

santhana Marimuthu wrote:1.Singleton represent object and Static class represent a method.

No.

2. Static class provides better performance than Singleton pattern, because static methods are bonded on compile time.

No.

3. One more difference between Singleton and static is, ability to override. Since static methods in Java cannot be overridden, they leads to inflexibility. On the other hand, you can override methods defined in Singleton class by extending it.

Yes.

4. Static classes are hard to mock and consequently hard to test than Singletons, which are pretty easy to mock and thus easy to test. It’s easier to write JUnit test for Singleton than static classes, because you can pass mock object whenever Singleton is expected, e.g. into constructor or as method arguments.

Yes.

[Jesper de Jong]

Welcome to the Ranch.

santhana Marimuthu wrote:1.Singleton represent object and Static class represent a method.

I don't understand what you mean by that exactly.

santhana Marimuthu wrote:2. Static class provides better performance than Singleton pattern, because static methods are bonded on compile time.

Maybe, but this is not necessarily true, and this should not be one of the major reasons why you would choose a class with static methods instead of a singleton class. The JVM does a lot of sophisticated optimizations, and one of those is replacing virtual method calls by direct method calls at runtime under certain conditions. So non-static method calls are not always more expensive than static method calls. Also, the performance impact of virtual method calls compared to direct method calls is not likely to be a performance bottleneck for most applications.

santhana Marimuthu wrote:3. One more difference between Singleton and static is, ability to override. Since static methods in Java cannot be overridden, they leads to inflexibility. On the other hand, you can override methods defined in Singleton class by extending it.

I agree about the (in)flexibility. However, if you're implementing a singleton properly in Java, you should make the class final (so that you cannot extend it), otherwise there is no way to guarantee that the class is really a singleton. Somebody could take your class, extend it, and put stuff in the subclass so that it isn't a singleton anymore.

santhana Marimuthu wrote:4. Static classes are hard to mock and consequently hard to test than Singletons, which are pretty easy to mock and thus easy to test. It’s easier to write JUnit test for Singleton than static classes, because you can pass mock object whenever Singleton is expected, e.g. into constructor or as method arguments.

I agree. When you have a singleton class, it's much easier to mock for testing than when you have a class with static methods.