General talk about software patterns

[Jesús Alonso <kenchoweb AT hotmail.com>]

Hi

Well, I don't actually see the point of it. I might be wrong, but a 
protected or private inner class can't be accessed from outside, so you 
can't instance it under demand, and thus you can't destroy the singleton 
instances.

In any case, writing a whole class for this purpose looks a bit overkill to 
me. In my opinion, as singleton instancing is a responsibility of the 
singleton implementors (using the GoF approach), the instence destroying 
should be so.

Best regards,
 Jesús Alonso Abad

> 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. :-)
>
>
>
> Thanks,
>
> Nitin Maheshwari
>
> CA, India


> _______________________________________________
> patterns-discussion mailing list
> patterns-discussion AT cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/patterns-discussion