about Singleton

[Timber Lee]

why does Singleton Permit a variable number of instances? what is its purpose?

[xiaolin yu]

I think to know why and how Singleton works, we need to know Java Virtual Machine structure. I don't know it either. I only know classes run in the same JVM calling Singleton class work on the same instance.
It provides a function similar to database. For example, we can use Singleton as the service locator to cache the class instance.

[Jack Coleman]

why does Singleton Permit a variable number of instances?

What are you asking exactly? Singleton does not permit a variable number of instances, it enforces the creation of only one instance.
As far as the second post goes, I didn't understand the point exactly. The JVM, or more specifically the Java application runtime, is itself the epitome of a Singleton.

 
   public class Runtime {
      private static Runtime currentRuntime = new Runtime();
      /**
       * Returns the runtime object associated with the current Java application.
       * Most of the methods of class <code>Runtime</code> are instance
       * methods and must be invoked with respect to the current runtime object.
       *
       * @return  the <code>Runtime</code> object associated with the current
       *          Java application.
       */
      public static Runtime getRuntime() {
          return currentRuntime;
      }
      /** Don't let anyone else instantiate this class */
      private Runtime() {}

[Rufus BugleWeed]

Singleton permits a variable number of instances because it controls a cache of instances.

[Thomas Taeger]

Originally posted by Rufus BugleWeed:
Singleton permits a variable number of instances because it controls a cache of instances.

Hi Rufus,
here Jack Coleman was quite right: "Singleton does not permit a variable number of instances, it enforces the creation of only one instance." That is what the design pattern is for; that makes it usefull.
"To control a cache of instances" is not typical for a singleton.
Where is your quotation or idea from? Seems that more people believe in that.
Thomas.

[Rufus BugleWeed]

4. Permits a variable number of Instances. The pattern makes it easy to change your mind and allow more than one instance of the class. Moreover, you can use the same approach to control the number of instances that the application uses. Only the operation that grants access to the Singleton instance needs to be changed.

page 128 Design Patterns: Elements of Reusable Object-Oriented Software by Eric Gamma, et al. Addison-Wesley Copyright 1995

The Singleton pattern has some similarity to the cache management pattern. A Singleton is functionally similar to a Cache that contains only one object.

page 133 Patterns in Java : Volume I by Mark Grand John Wiley and Sons Copyright 1998
Times have changed and Grand's book is a better buy than the GOF. But that's where the rift starts.

Someday I hope to find time to read -
When is a Singleton Not a Singleton?
HTH
[ January 29, 2003: Message edited by: Rufus BugleWeed ]

[Thomas Taeger]

Hi Rufus,

Originally quoted by Rufus BugleWeed:

"allowing the flexibility to create more objects if the situation changes"

is true and may be usefull in those situation mentioned in that article, but in my opinion this leaves the singleton pattern then and goes to another [which one?] usefull design pattern.

Originally posted by Rufus BugleWeed:

When is a Singleton Not a Singleton?

Thank you for that link, really interesting.

Especially the following sentence of that article was very interesting to me:

Originally _quoted_ by Rufus BugleWeed:

"The only practical solution is to synchronize the getInstance() method"

i.e.:
public static synchronized MySingleton getInstance() { ...
because I would not have trusted a static methad to synchronize. I would have missed the object on which to synchronize its methods. But that was just the coarsest way of synchronization (instead of on methods themselfes).

Good old Flanagan "Java in a Nutshell" (1.0!), page 161:

using synchronized to prevent access by multiple threads to critical data structures

- not only to critical objects allowing to be referenced by "this".

Flanagan "Java in a Nutshell", p. 46:

synchronized: ... mark[s] a critical section of code. The same keyword can also be used as a modifier for class or instance methods.

Thomas.

[Rufus BugleWeed]

Eric Gamma, et al is the gang of four. I suspect they first documented the pattern. Time have changed and their work has not.
Sun knows this and the exam is not try to have one resolve conflicts in the patterns section.

[Jack Coleman]

Thanks for those links Rufus. I like the author's conclusion in the article "When is a Singleton Not a Singleton".

Singletons are a useful way to control access to a class, making sure that only one instance can exist. In some none-too-uncommon circumstances, however, multiple instances can occur, even in a class coded as a Singleton. By being aware of the possibility, you can be sure that your Singleton really is a Singleton.

When the Singleton behaves "not like a Singleton" shouldn't we call it something else? (like Thomas said) Maybe a Polyton or a Pool?
The whole purpose of design patterns is to have a "language" to discuss these kinds of things, and when we use Singleton to discuss pooling and cacheing, I think it loses it meaning.