Win a copy of Kotlin in Action this week in the Kotlin forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

Singleton  RSS feed

 
john cahil
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Q1 Is there any possible way to make a class Singleton with out making a constructor private or protected?

Q2 Is there any possible way to make a class Singleton with out using Instance variable or static variable ?
 
Arafat Nalkhande
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
the answer to both questions is NO.
And well the instance variable has nothing to do with a singleton class.
You just need a static variable to hold the referance to the sole object.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Answer to both is YES. I can think of two or three ways. Look into package visibility and inner classes. See what comes to you.
 
Arafat Nalkhande
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Stan, can you please throw some light on your comment.
I am particularlyu interested in knowing how to have a singleton without the usage of static variable
 
Adam Nace
Ranch Hand
Posts: 117
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Arafat Nalkhande:
Stan, can you please throw some light on your comment.
I am particularlyu interested in knowing how to have a singleton without the usage of static variable


I don't know hwat Stan was thinking, but let me outline a possibility for you:

You have an object called a Singleton Instance Manager. That Manager is responsible for maintaining a list of singleton instances. It is the object that creates the singletons, and the access point through which those instances can be retrieved. It holds those instances in a list or map, which means that the class defining the singleton's type does not store any instances at all, and the Singleton Instance Manager does not store any of the instances in variables called someTypesInstance, but rather in a single instance variable which is a collection. (The Singleton Instance Manager is likely a Singleton itself, and probably needs a static variable to store it's own instance, but any other Singleton that it contains do not need static variables).

Bottom line: Singleton basically requires that only one single object is ever created. That doesn't mean that it is not POSSIBLE to create more than one object. It means that uncontrolled code cannot create a second object of that class. Look into access modifiers (particularly package protected access), and look into private inner classes, and you should start to see that the class defining the singleton's type does not have to be the class that holds the reference to that single object, and does not necessarily have to make sure it's constructors are private or protected.

- Adam
[ August 01, 2006: Message edited by: Adam Nace ]
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I spoke too fast ... the normal Java implementation of the pattern has a class with a static reference to an instance of itself. That's the part I wanted to say is not necessary.

A static (global) anchor somewhere in the chain - factory or cache or something - is the natural mechanism to provide access to a singleton. I wonder if you could store a singleton in JNDI instead of a static variable? Do we have any other global mechanisms?

Mostly I wanted to challenge this:

That's a quick, easy, usually perfectly acceptable way to do singleton, but not the only one. Think about other ways to meet the two requirements: control the number of instances by preventing any old class from doing new() or newInstance(), and provide an access mechanism for instances.
[ August 01, 2006: Message edited by: Stan James ]
 
Arafat Nalkhande
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks Adam and Stan!!!
This is now getting really interesting.

Adam : I think if the InstanceManager class can create an object of the singletn class then any damn XYZ class can do this as well.

My idea of singleton is that even if somebody wants to mischievously create more than one instance then he should not be able to do so, and this can be achieved only if the constructor is private and can be accessed only by the same class.
Well I agree with Stan that probably we can use the JNDI binding instead of the static variable holding the referance.
Another dirty way can be serialize/deserailize the object and use file system to store it.

So this solves the 2nd question and the answer is YES.
Well but still I am of the opinion that constuctor has to be private (not even protected). Because only then 100% robustness is achieved and the singleton will always remain a singleton, however hard someone tries to break it.
Any comments on this part...
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Stan James:

A static (global) anchor somewhere in the chain - factory or cache or something - is the natural mechanism to provide access to a singleton. I wonder if you could store a singleton in JNDI instead of a static variable? Do we have any other global mechanisms?


The application context of a servlet container?
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I wondered about servlet contexts. Don't you suppose they're held by a static somewhere? Would that count?

Other ways to control creation ... See if you can make a factory in one package create an instance of an object that nobody in any other package could create. Or an object that creates an instance of some inner class that nobody else could create. These might lead you to hidden implementations of a public interface, which sounds interesting.
 
Piyush Tamboli
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would anyone please explain where exactly we need only one instance to be created in actual practice

Thanks in Advance !!!
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
There's also the possibility of "runtime enforcement." The constructor might look like



The implementation of anInstanceHasAlreadyBeenCreated() might use whatever tricks you'd like to satisfy criterion number 2.
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Would anyone please explain where exactly we need only one instance to be created in actual practice


A couple places come to mind. One is when we need an anchor for global data, like a cache.

You could do this with a static method on Cache but that has its own pros & cons.

Another time we use Singleton is when we believe creating and garbage collecting a lot of objects would be too much overhead. (We may or may not be anywhere near correct when we think this!) Then we can create one instance and share it among many threads or many trips through a bit of logic. Which of course has its own pros & cons again.

The servlet container does something very much like the second case. It creates some small, controlled number of instances of each servlet. (We usually assume exactly 1 but there's no guarantee, I think.) Servlets can have a public constructor so it's not exactly Singleton. We often call it Just Make One. You could make more but they wouldn't do anything useful, so you just know better than to do it.
 
Ilja Preuss
author
Sheriff
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
There's also the possibility of "runtime enforcement." The constructor might look like



The implementation of anInstanceHasAlreadyBeenCreated() might use whatever tricks you'd like to satisfy criterion number 2.


I don't think that's a fully fledged GoF Singleton, because it's missing the global access point to the one valid instance.

But I prefer the Just Create One pattern, anyway...
 
john cahil
Greenhorn
Posts: 12
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
public Singleton() { if (anInstanceHasAlreadyBeenCreated()) throw new RuntimeException("Singleton!");}


--------------------------------------------------------------------------------



The implementation of anInstanceHasAlreadyBeenCreated() might use whatever tricks you'd like to satisfy criterion number 2.

------------------------------------------------------------------------------
I do not think this is the proper way because as far as I know constructor is callede after memory allocation of an object, although I agree that no one can acess it , but althogether it is not a good programming practice ,things will be difficult when we think what is next in this scenerio like what we are going to do while catching that Exception
 
Arafat Nalkhande
Ranch Hand
Posts: 51
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ernest Friedman-Hill:
There's also the possibility of "runtime enforcement." The constructor might look like



The implementation of anInstanceHasAlreadyBeenCreated() might use whatever tricks you'd like to satisfy criterion number 2.



Thanks Ernst, now question 1 also gets a convincing YES answer.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!