Can some body explain me advantange of making a class single ton over making all attribute and Operation static? I know Single ton means user can create only instance of the object. Can't same functionality be achieved by making all attributes and operations in class static and making constructor private to prevent them from making instance?
Advantages or disadvantages depends on the situation. However,
I would say that they are hard to compare to begin with. A
singleton is a design pattern which is far more flexible. I
give you an example. Let Calculator.java be an interface which
implements stateless services. Assume that we have a factory
or a micro kernel like http://jakarta.apache.org/hivemind/ then
we can provide different singleton implementations to clients.
This can be smart because the different calculators might be
specialized by fulfilling the contract in different ways.
You can also not access internal classes from a static method.
> Can't same functionality be
> achieved by making all attributes and operations in
> class static and making constructor private to
> prevent them from making instance?
Yes, but it would not be an OO Solution.
Some people consider the Singleton not to be good OO either, but for most it is a necessary evil.
Depending on your experience and your views you may not consider that to be a problem. Well until you try to maintain or reuse any of it.
> Can some body explain me advantange of making a class
> single ton over making all attribute and Operation
> static? I know Single ton means user can create only
> instance of the object. Can't same functionality be
> achieved by making all attributes and operations in
> class static and making constructor private to
> prevent them from making instance?
As parz alluded to, the main advantage of a Singleton over a set of static methods is that static methods are not polymorphic. This leads to how Singletons are often misunderstood in Java. A true Singleton is a Factory. It's configurable to load different implementations at runtime. Often, Singletons in Java do not have this quality. When they don't do this, they don't offer much advantage over a set of static methods. One exception, though, they can implement interfaces, which cannot be done with a set of static methods.
I only use static methods as helper methods. In general they are package scope. I dont use any singletons except where some external architecture has foisted them upon me. Such as Eclipse. And even now I joined in a bug report/enhancement that would get rid of this. Its not really needed in eclipse since the change to osgi, and looks like a problem waiting to happen.
I do however use a multiton which serves a different purpose. Can't see any advantage in singletons over static methods.
> I know Single ton means user can create only
> instance of the object.
You can use more than one instance in singleton pattern if you want. But, in this case, the name "singleton" wouldn磘 be appropriate.
In most of cases only one instance is used in singleton. It is more usual. But you can use more than one instance, limiting the number of active instances of your singleton. You can achieve this using an array that will contain instances of this singleton. You can set this array with an amount of elements that corresponds with the maximum amount of instances of this singleton.
I don磘 know preciselly if the performance of the application is better when you define, for example, 5 instances of your singleton at the most, rather than only one instance. I just mention this because I磛e already seen something like this. Maybe it improves the performance, I don磘 know....
An advantage of using a singleton instead of a static class is that you have a reference to an object. This means you can pass it around as a parameter.
The advantage of this is that some module needs an instance of something that implements an interface, but has no idea that this particular application uses a singleton and so could as well call the static methods directly.
So decoupling is the main advantage I think.
You must have carrefull with this comparison...
Because in pratic (in development)....both have the same functionality...
But read this..:
Singleton is a great designer patterns,...that usually is a decision of api, framework or architeture of the softwares and static members is a resource that only "SHARING" its by all instances of the class.
You can see that Syngleton Pattern use static resource...but what must be to consider is: If you are using a short application, maybe can use static members to control...but if you are development a big application...maybe need make a framework or a self api...where static members can't !!!!!!! resolving all the controls.
So....I believe that you can't to compare a java resource with a designer pattern...BECAUSE them have differents use types.
Sorry by mistakes..because I still learning the english language.
From what I understand, a static class is meant to hold standalone functions, and to store little or no state (e.g. the Math class). A singleton, however, should be used when there's state to store, or the object represents a singleton resource in the real world (e.g. the Runtime class).
~Cheers
> From what I understand, a static class is meant to
> hold standalone functions, and to store little or no
> state (e.g. the Math class). A singleton, however,
> should be used when there's state to store, or the
> object represents a singleton resource in the real
> world (e.g. the Runtime class).
That's often how it ends up but there's no reason a 'static class' cannot hold state.
Static method, no need instance of the object.
Singleton, need one instance of object and keep the state.
example:
Factory method of a Object, you could use a static method in order to create different class that extends the same abstract class (o that implement the same interface).
A socket connection to a server, you could use a singleton in order to reuse only one connection. It is posible that the server only allow
a connection by IP.
Thanks you
Can't remember where I read about this, but I do recall reading that the singleton pattern emerged largely due to the fact that you can't control the order of static initialisation in C++ - hence the need for a pattern that simulated a static class but where you had a constructor / init method to give this control - eg. imagine creating a database connection which required some other data to be ready first, reading an env parameter or suchlike.
Java on the other hand provides just such a means, the static initialisation block. May well be that singletons in java are largely a hangover from this c++ tradition.
I appreciate the arguments about being able to pass have the singleton implement an interface, and pass it as a reference to other classes that might not be aware that it is a singleton, but have never seen such a case in real code.
If you look at the Runtime class, you'll see that it has a method that returns a singleton object, getRuntime(). So why does this exist, instead of just making all the methods of Runtime be static?
Because there are different implementations of the API, to run on different platforms, and each implementation will provide an instance of its own subclass of Runtime, customized to run on one platform. The all-static-methods idea wouldn't work here because static methods aren't inherited like instance methods are. It isn't obvious to me why Runtime has to be a singleton, but I suppose there are reasons for that.
You'll find other examples in e.g. the AWT package where it interfaces with the underlying platform's GUI support.
> > I know Single ton means user can create only
> > instance of the object.
>
> It doesn't really. The Singleton pattern allows you
> to create a limited instances of an object. That's
> the gist of Singleton. You cannot make any number of
> objects.
Huh? The singleton is limited to one and only one object instance.
The multiton allows more than one.
> Huh? The singleton is limited to one and only one
> object instance.
Only in the mothership. Here on earth where the GoF book was written the Singleton patterns means a limited number of objects.
> The multiton allows more than one.
It's just a joke. There's no Multiton pattern.
> > Huh? The singleton is limited to one and only one
> > object instance.
>
> Only in the mothership. Here on earth where the GoF
> book was written the Singleton patterns means a
> limited number of objects.
From the book "Design Patterns" by the GoF....
-
Use the Singleton pattern when
- there must be exactly one instance of a class, and it must be accessible to clients from a well-known access point.
...
Implementation
...
1. Ensuring a unique instance. ...
-
Now on my mothership "one" means the integer number that comes between zero and two. And in the language of my mothership it never represents a plural. Nor does "unique".
>
> > The multiton allows more than one.
>
> It's just a joke. There's no Multiton pattern.
So...
1. Can't be a Singleton because that isn't what "Design Patterns" says.
2. And you seem to suggest that there is a pattern where a limited number of instances exist.
So what exactly is that pattern called?
Actually, u....j... does have a point.
If you look at the Consequences section of the Singleton pattern in the GoF's "Design Patterns" book, they do go on to say:
4. 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....
However, I myself agree with you, that in that case, it should be re-labeled as a Multiton. The long-gone, but not forgotten page patterndigest.org (or com?) did list a Multiton.
We're talking Semantics here people, and personally, to avoid the confusion, it should really be re-labeled Multiton, a pattern Related to the Singleton. The name itself points to the fact that there should be a Single Instance.
What if static or singleton class are hide.!
Then you will get only one solution for singleton.
For example :
You have got serveral (unsynchronized) threads which have access to your static(singleton) class. Threads are adding objects to your List in this speciall class. So if you use singleton, and one thread will finsh his job the list will become null.
So if you need to remember the state of the object whenever you want, I think that you should use static class.
> Actually, u....j... does have a point.
>
> If you look at the Consequences section of the
> Singleton pattern in the GoF's "Design Patterns"
> book, they do go on to say:
>
> 4. 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....
>
i think it meant to say the singlton pattern lets you have some control over the number of instances you can create. then not only if it still a singlton in its original sense is a arguable, it can also be done with a static class as well. i dont think there is a difference in that area.
I agree with David_Waddell in that concrete Runtime class could have been bundled with JRE. But what if my design requires the Singleton object dynamically?
e.g. I have interface DB. I want the implementation to be Singleton. I have two implementations: RDBMS and OODB. Depending on client request I will instantiate any of those.
I don't think the Singleton and static class here are comparable. Singleton is a pattern and static class is language construct. In fact Singleton object (with instance methods) itself is static inside its class. They are the same. Above example could have been handled by static classes but with some non-OO coding and at the expense of extensibility. Singleton pattern is more elegant solution.
