General talk about software patterns

["Sriram Gopalan" <Sriram.Gopalan AT agile.com>]

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:eric AT eyt.ca]
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
patterns-discussion AT cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/patterns-discussion