General talk about software patterns

[Peter Sommerlad <psommerlad AT hispeed.ch>]

Hi James, hi all

Siddle, James wrote:
> Hi Peter,
>
> Could you recommend an alternative approach to singleton when applying cross
> cutting concerns to legacy code?
>
> Let me elaborate...the C++ project I'm currently working provides a nice
> framework & general approach to accessing the current 'context', e.g. an
> element sitting in the framework can get hold of a variety of objects via a
> "framework context". This is an interface that is actually provided by the
> overall framework container.
>
> However, the project must also provide exception handling & logging to a
> large quantity of legacy code...so we wrote a couple of singleton classes to
> fulfil those roles. Are there any alternatives you could recommend to this
> approach?
in a similar context we used a Context object passed through all method 
calls in the framework. This collected all globally needed information. 
There is also a pattern called Execution Context by Alan Kelly if I 
remember correctly, describing that mechanism.
see http://www.allankelly.net/patterns/#EncapsulateContext

Using a mock-Context makes testing such code much easier! However, you 
might need to ajdust your APIs to add this Context parameter.

Yours
Peter.

> Thanks,
> Jim
>
>
>
> -----Original Message-----
> From: Peter Sommerlad [mailto:psommerlad AT hispeed.ch] 
> Sent: 03 April 2006 06:00
> To: Maheshwari, Nitin
> Cc: 
> patterns-discussion AT cs.uiuc.edu
> Subject: Re: [patterns-discussion] Singleton Pattern by John Vlissides
>
> 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