I think it should be OK for the singleton instance to be removed and restored without violating the pattern in any way. After all, the whole purpose is to isolate and encapsulate the lifecyle of the singleton within its own class, so that the rest of the application doesn't need to worry about it.
There should be no assumption from the client code that the exact same reference would be returned for successive calls to Singleton.getInstance(). -----Original Message----- From: Eric Y. Theriault [mailto:[EMAIL PROTECTED] Sent: Sunday, October 03, 2004 2:39 PM To: Ashish Harigopal Poddar Cc: patterns-discussion Subject: Re: [patterns-discussion] deleting a Singleton Ashish Harigopal Poddar wrote: >singleton does not defines the lifetime of the class i agree to that.. but >what i was suggesting was that logically speaking, the singleton object should >not be destoyed in between the life of the application, because that wud >distort the basic idea of the pattern, because others demanding a copy after >that wont get the same copy. > > I think that this all depends on the Singleton. In the case of a Keyboard, then yes, I agree with you, since all clients of the object should be receiving the same object. But in this example, it is a lifetime and constraint issue. It is a lifetime issue since the Keyboard should have a similar lifetime to the application, and it is a constraint issue since most computers only permit a single keyboard. But the Singleton pattern does not enforce these issues. The fourth consequence clearly indicates that the Singleton design pattern can control the number of objects rotating around a system. In other words, it could be used to implement a pool of database connections, for example, where clearly clients requesting an instance will not necessarily acquire the same instance. Furthermore, in Modern C++ Design, Andre Alexandrescu also mentions the Phoenix Singleton, whereby a Singleton that was once destroyed would be reconstructed. His example surrounding this is lifetime of the Keyboard, Display and Log singletons, where he desires the Log singleton to be destroyed last, since he wishes that the Keyboard and Display destruction errors be logged, and he proposes a scheme where your Singletons could be destroyed out of order and reconstructed in the event that they are required. (This summary does not give Andre's analysis justice; please refer to his book). In continuing with the database connection pool example, it is also possible that this database connection pool would only be used for a finite portion of the application. For example, it may only be used to load some user data into memory at the start of the application, and adapt this information into another form (such as an XSLT processor). Per se that the data loading segment of the application is a small factor of the overall application and that the database is not required during the remaining processes; under these circumstances, does it make sense that the database connections remain active during this remaining lifetime of the application? I do not think so. This example has some flaws in it; it is not meant to be the catch all scenarios (especially since the Singleton object's creation of N database connections does not mean that it could not most of those connections and to completely disconnect from the database until an instance request is requested, essentially converting the Singleton into a Proxy). These issues aside, there are cases where the lifetime of the Singleton is not the entire lifetime of the application. I presume that by implementing the Singleton via a Proxy or the pImpl idiom that many of these issues could be dealt with though. eyt* -- Eric Y. Theriault http://www.eyt.ca _______________________________________________ patterns-discussion mailing list [EMAIL PROTECTED] http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion _______________________________________________ patterns-discussion mailing list [EMAIL PROTECTED] http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion
