General talk about software patterns

[Peter Sommerlad <psommerlad AT hispeed.ch>]

Singleton should be VERBOTEN!

using singleton is like using global variables -> too much coupling, bad 
testability. The stack and method parameters are your friend!

just my 0.02 CHF
Peter.

Maheshwari, Nitin wrote:
> Hello,
>
>  
>
> I am reading "Pattern Hatching" by John Vlissides 
> (http://www.research.ibm.com/designpatterns/pubs/ph-jun96.txt). And I 
> have come across the Singleton Pattern. The way to use a 
> SingletonDestroyer (SD) class to “KILL a Singleton instance” has 
> fascinated me.
>
>  
>
> I am a novice in this field as compared to most of the members and based 
> on my limited knowledge I have tried to come up with a slightly 
> different approach of destructing a singleton. So you are more then 
> welcome to send your comments on flaws in my approach.
>
>  
>
> In John’s approach, destructor is made protected so that the user is not 
> allowed to delete the singleton instance explicitly, also as said 
> Singleton class has the responsibility to construct and destruct its 
> instance. For this reason a separate class SD is introduced, which is a 
> friend of class Singleton. Class Singleton also has a static member of 
> SD. So as the SD’s instance goes out of scope, it deletes the pointer of 
> Singleton assigned to it. SD has public constructor and a setter 
> function to set the Singleton pointer.
>
>  
>
>     class SingletonDestroyer {
>
>     public:
>
>         SingletonDestroyer(Singleton* s= 0) { _singleton = s; }
>
>         ~SingletonDestroyer() { delete _singleton; }
>
>  
>
>         void SetSingleton(Singleton* s) { _singleton = s; }
>
>     private:
>
>         Singleton* _singleton;
>
>     };
>
>  
>
>     class Singleton {
>
>     public:
>
>         static Singleton* Instance();
>
>     protected:
>
>         Singleton() { }
>
>  
>
>         friend class SingletonDestroyer;
>
>         virtual ~Singleton() { }
>
>     private:
>
>         static Singleton* _instance;
>
>         static SingletonDestroyer _destroyer;
>
>     };
>
>  
>
> Having a public SD constructor give a chance to user to create the SD 
> object explicitly, such as:
>
>        
>
> Singleton *pSingleton = Singleton::Instance();
>
> SingetonDestroyer explicitSingletonDestroyer(pSingleton);
>
>  
>
> So the basic purpose of making the destructor of Singleton protected is 
> defeated.
>
>  
>
> I have made a minor change in John’s approach to rectify this problem. 
> Class SD is made the protected inner class of class MySingleton. This 
> prevents the user from creating an instance of SD class explicitly and 
> thus restricting the user to delete the Singleton pointer knowingly or 
> unknowingly.
>
>  
>
> class CMySingleton 
>
> {
>
> protected:
>
>         class SingletonDestroyer  // Inner Class
>
>         {
>
>         public:
>
>                 SingletonDestroyer () {}
>
>                 ~SingletonDestroyer () {
>
>                         delete _pInstance; // deleting the singleton 
> instance
>
>                 }
>
>         private:
>
>                 // Prevent users from making copies of a
>
>                 // Destroyer to avoid double deletion:
>
>                 SingletonDestroyer(const SingletonDestroyer&);
>
>                 void operator=(const SingletonDestroyer&);
>
>         };
>
>  
>
>         friend class SingletonDestroyer;
>
> protected:
>
>       CMySingleton();
>
>       virtual ~CMySingleton();
>
> public:
>
>         static CMySingleton* GetInstance ();
>
>         void DoSomething();
>
> protected: //members
>
>         static CMySingleton *_pInstance;
>
>         static SingletonDestroyer _destroyer;
>
>         int _nSomeVal;
>
> };
>
>  
>
> It still doesn't help you if you need to delete your singleton *before* the 
> end of the program. J
>
>  
>
> Thanks,
>
> Nitin Maheshwari
>
> CA, India
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion

--
--
Peter Sommerlad

Erlenstrasse 79
CH-8832 Wollerau
tel    +41 1 687 44 74
fax    +41 79 432 23 32
mobile +41 79 432 23 32
mailto:psommerlad AT hispeed.ch