www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - Singleton pattern in D

reply BLS <nanali nospam-wanadoo.fr> writes:
I would like to implement the  GoF patterns in D, I have to start somewhere and
 found the Singleton pattern interesting ( to say the least )

Here a simple *C Sharp* implementation :

class Singleton
  {
    private static Singleton instance;

    // Note: Constructor is 'protected'  ...  why not private ?
    protected Singleton() 
    {
    }

    public static Singleton Instance()
    {
      // Use 'Lazy initialization' 
      if (instance == null)
      {
        instance = new Singleton();
      }

      return instance;
    }
  }

My thoughts
D classes do not have nessesarily an constructor.
OR How would you implement this pattern D

In general :
Patterns allways have a bad side-effect, you can not really re-use them. 
What about using D MIXINS/ MIXIN Templates and Interfaces to make pattern more
re-useable, more universal . Opinions ?

regarding the singleton :
(probabely a quit stupid question)
What about static this()... can this D feature be usefull

Many Thanks in advance Bjoern
May 11 2007
next sibling parent reply Daniel Keep <daniel.keep.lists gmail.com> writes:
I made a singleton implementation a while ago, although I'd have to say
it was *very likely* overkill (I do that).

Basically, it was a part of my class registry stuff.  Long story short,
you did this:

 interface MyInterface
 {
     void foo();
 }

 class MyClass : MyInterface
 {
     void foo() { writefln("bar"); }
 }

 static this()
 {
     classreg.registerSingleton({return new MyClass;});
 }

Then, in your code, you would get an instance like so:
 classreg.getInstance!(MyInterface);

Which would always return the same instance. Again, it's probably overkill for what you want. If you want to make singleton a little easier to use, maybe a mixin would help:
 template Singleton()
 {
     private this()
     in
     {
         assert( instance is null );
     }
     body
     {
         // Put your initialisation stuff in init_singleton.
         static if( is( typeof(this.init_singleton) ) )
             this.init_singleton;
     }

     private static typeof(this) instance;

     public static typeof(this) getInstance()
     {
         if( instance is null )
             instance = new typeof(this);
         return instance;
     }
 }

 class SingletonClass
 {
     mixin Singleton;
 }

Note: not tested, but something along those lines should do you. Final point: just make sure you actually need singleton. I've seen a lot of people using singleton for a single class, which would be more efficiently handled by a static class. -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
May 11 2007
next sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples? I use singleton pattern e.g. for the application class (command line interface), configuration class (configuration handling), an log class (logging). Regards, David
May 11 2007
next sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
David Ferenczi wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples? I use singleton pattern e.g. for the application class (command line interface), configuration class (configuration handling), an log class (logging).

Good ole Yegge comes through again here with another beautiful rant: http://steve.yegge.googlepages.com/singleton-considered-stupid
May 11 2007
next sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Bill Baxter Wrote:

 David Ferenczi wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples? I use singleton pattern e.g. for the application class (command line interface), configuration class (configuration handling), an log class (logging).

Good ole Yegge comes through again here with another beautiful rant: http://steve.yegge.googlepages.com/singleton-considered-stupid

Seriously RoR is based on patterns. MVC is a pattern. Signal-Slot is a pattern ...A Texteditor as GUI framework is implemented using patterns. So I think patterns have nothing to do with nostalgic feelings. I think that implementing patterns using modern D features will make patterns much more usefull in a "Good ol OOP" sense. Agreed ? Again just my opinion, Martin Fowlers Enterprise pattern have had an big impact in the db-developer scene.. My 2 cents Bjoern
May 11 2007
prev sibling next sibling parent reply David Ferenczi <raggae ferenczi.net> writes:
Bill Baxter wrote:

 David Ferenczi wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples? I use singleton pattern e.g. for the application class (command line interface), configuration class (configuration handling), an log class (logging).

Good ole Yegge comes through again here with another beautiful rant: http://steve.yegge.googlepages.com/singleton-considered-stupid

An interesting read. Thank you.
May 11 2007
parent reply David Ferenczi <raggae ferenczi.net> writes:
 An interesting read. Thank you.

I'll try to summerise the article: 1. Singleton is evil. 2. Everyone, who uses singleton, is a beginner (or nerd?) and doesn't understand the OO paradigm. 3. There are many problems with singletons, see section "Get to the Point, Already". 4. If you want to use singleton, use a static class or a factory instead. IMO the problems with singleton implementations are valid, but he forgets to mention that exactly the same applies for static classes. Static classes are just more effective (you save a function call) and syntactically nicer (in the class itself, and also wehne calling). But is there really more? Are singletons really so evil, that worth bashing? And can the factory pattern be applied everywhere, where you need a singleton (static availability, only one instance)? I'm not sure. Do I miss something? Regards, David
May 11 2007
parent Bill Baxter <dnewsgroup billbaxter.com> writes:
David Ferenczi wrote:
 An interesting read. Thank you.

I'll try to summerise the article: 1. Singleton is evil. 2. Everyone, who uses singleton, is a beginner (or nerd?) and doesn't understand the OO paradigm. 3. There are many problems with singletons, see section "Get to the Point, Already". 4. If you want to use singleton, use a static class or a factory instead. IMO the problems with singleton implementations are valid, but he forgets to mention that exactly the same applies for static classes. Static classes are just more effective (you save a function call) and syntactically nicer (in the class itself, and also wehne calling). But is there really more? Are singletons really so evil, that worth bashing? And can the factory pattern be applied everywhere, where you need a singleton (static availability, only one instance)? I'm not sure. Do I miss something?

I agree that Singleton is overused. But I think it's overused in the same way that stubbed out copy constructors are overused. Everyone knows they should provide a reasonable copy constructor for their classes, but y'know getting the darn thing working at all is often a much higher priority than than figuring out the details of safely copying a complicated object. So rather that not doing anything and letting the compiler merrily supply a bogus copy constructor that will appear to work at first, you stub it out so anyone who tries knows that you haven't done the work yet. I think many times Singletons are used in the same vein. "Yeh, I know some day there could be more than one Renderer instance, but there isn't now and I'm not really ready to deal with it". So you put all the renderer bits in a Singleton, and make everyone who wants to use it call getInstance(). Steve says that makes for a horrible refactoring experience when suddenly you do need more than one instance, but to me it seems much better than if you had started out with globals. You can convert the getInstance() method into a static factory method that takes some kind of parameter to select the instance desired, and you're good to go. For example you can change it so that getInstance("directX") give you the directX renderer, and maybe leave getInstance() as returning the 'default' renderer so old code still works. Seems all in all much easier refactor to me than if you than if you had started out with a bunch o globals. --bb
May 12 2007
prev sibling parent Daniel Keep <daniel.keep.lists gmail.com> writes:
Bill Baxter wrote:
 David Ferenczi wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples? I use singleton pattern e.g. for the application class (command line interface), configuration class (configuration handling), an log class (logging).

Good ole Yegge comes through again here with another beautiful rant: http://steve.yegge.googlepages.com/singleton-considered-stupid

In my *defense* 'yer honah, I was using singleton instances for the rendering and input subsystems for a game, of which there was only one linked into the executable. The reason I did all that was because I wanted to be able to say engine.gx.Gx.doStuff() Instead of: engine.gx_sdl_gl20.gx.Gx.doStuff() Sadly, D doesn't have runtime class variables, so I kinda had to fake it :P I could have used an alias, but that would have, again, involved actually referring to the concrete class at some point. All this because I wanted to be able to pull out the renderer and change it without having to touch a line of code anywhere else. I swear, one of these days I'll stop doing all this crazy stuff just to avoid changing a few lines of code :P ... naaah. -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/
May 11 2007
prev sibling parent reply janderson <askme me.com> writes:
David Ferenczi wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Can you mention some godd and bad examples?

In my option: Good examples: The singleton needs to be created/destroyed You need to: - create some sort of resource - file handle - deal with something that is not available until a certain time in execution. - To save memory by not always having the skeleton available and use the RAII to make the singleton only available when necessary. Bad example: - You have something thats always available during the entire project and no initialization/destruction is necessary. For instance, it would be a bad idea to create a maths library with things like cos and sin in it (unless you wanted to generate some sort of fancy lookup table at run-time which requires initialization). - Performance critical code. For things that are included in your most inner loops, you don't want the overhead of an extra pointer lookup. (note that inline'ing can sometimes cure this problem if used in the local project) Why? Singletons add code bloat both in the interface and in use. It means more reading, more typing, more debugging and slower compiles. Also it means that things become harder to refactor because they are closely coupled to a class. Rant: Personally I think some people use OOP to much. I'm no expert however this is where I'm currently at with my coding ethic: 1) Use free functions when they make sense. Free functions are easy to move around. If it's in the class its one more attribute you have to maintain when that class is inherited from or move around. Also free functions can be more generalized. 2) Use inheritance for polymorph only. Avoid using inheritance for code reuse. This way the class becomes more manageable. 3) Use components class for code reuse. If the component changes it has less effect on the interface of the owner class. 4) Use small classes that have one function as they are much more re-useable and debugable. However, I concede that it can be much faster to write a big class then lots of scaffolding small classes, particularly in the short term. 5) Don't write getter/setter methods if the class simply exposes everything anyway, use a struct instead. Getter/Setters should be used for classes that do more then just provide access properties, its just unnecessary code bloat that is time consuming to maintain. 6) If programming in C++ don't write extremely complex templates. They slow slow down compilation and confuse everyone else. Do use templates for generalization just don't go overboard and beware of code bloat issues. If programming in D, go nuts with templates. 7) Use constant lookup tables/arrays (or datadriven tables) instead of switch statements and if statements, where possible. These are easier to maintain. For instance it makes it easier to register/remove new types. It also helps keep all the information together that is meant to be together. 8) Scaffolding = time. Scaffolding takes time to write, compile and maintain. Try to minimize scaffolding and keep most of the code actually doing something useful, without sacrificing readability. 9) Perfect is the enemy of good. Don't over design. Get the fundamentals and then add as needed. Particularly if your writing code that is application code or internal to a library (with public libraries you don't know what your users will need).
May 12 2007
next sibling parent janderson <askme me.com> writes:
janderson wrote:
 David Ferenczi wrote:
  >> Final point: just make sure you actually need singleton.  I've seen a
  >> lot of people using singleton for a single class, which would be more
  >> efficiently handled by a static class.
  >
  > Can you mention some godd and bad examples?
  >

 9) Perfect is the enemy of good.  Don't over design.  Get the 

 Particularly if your writing code that is application code or 

 you don't know what your users will need).

That should be: ... Particularly if your writing code that is application code or internal to a library. This approach of course doesn't not work for public library interfaces where the more flexibility provided the better. Now I only wish I could always follow my own advice ;) -Joel
May 12 2007
prev sibling parent David Ferenczi <raggae ferenczi.net> writes:
Thank you very much!
May 12 2007
prev sibling parent BLS <nanali nospam-wanadoo.fr> writes:
Thanks Daniel,
both solutions are VERY slick. (especially the DBC implementation  is a great
help for me)

I will pick up solution No. 2 make getInstance() synchronized in order to make
it thread safe.

Daniel wrote:
 Final point: just make sure you actually need singleton.  I've seen a
 lot of people using singleton for a single class, which would be more
 efficiently handled by a static class.

Good point. Concrete case is that I would like to use the Singleton Pattern in conjunction with the abstract factory pattern to access different databases. Database specific factories are created which themselves are Singletons. ---like in M.Fowlers Enterprise patterns. But : First things first. Again many thanks! Bjoern Daniel Keep Wrote:
 
 I made a singleton implementation a while ago, although I'd have to say
 it was *very likely* overkill (I do that).
 
 Basically, it was a part of my class registry stuff.  Long story short,
 you did this:
 
 interface MyInterface
 {
     void foo();
 }

 class MyClass : MyInterface
 {
     void foo() { writefln("bar"); }
 }

 static this()
 {
     classreg.registerSingleton({return new MyClass;});
 }

Then, in your code, you would get an instance like so:
 classreg.getInstance!(MyInterface);

Which would always return the same instance. Again, it's probably overkill for what you want. If you want to make singleton a little easier to use, maybe a mixin would help:
 template Singleton()
 {
     private this()
     in
     {
         assert( instance is null );
     }
     body
     {
         // Put your initialisation stuff in init_singleton.
         static if( is( typeof(this.init_singleton) ) )
             this.init_singleton;
     }

     private static typeof(this) instance;

     public static typeof(this) getInstance()
     {
         if( instance is null )
             instance = new typeof(this);
         return instance;
     }
 }

 class SingletonClass
 {
     mixin Singleton;
 }

Note: not tested, but something along those lines should do you. Final point: just make sure you actually need singleton. I've seen a lot of people using singleton for a single class, which would be more efficiently handled by a static class. -- Daniel -- int getRandomNumber() { return 4; // chosen by fair dice roll. // guaranteed to be random. } http://xkcd.com/ v2sw5+8Yhw5ln4+5pr6OFPma8u6+7Lw4Tm6+7l6+7D i28a2Xs3MSr2e4/6+7t4TNSMb6HTOp5en5g6RAHCP http://hackerkey.com/

May 11 2007
prev sibling next sibling parent Mike Parker <aldacron71 yahoo.com> writes:
BLS wrote:
 I would like to implement the  GoF patterns in D, I have to start somewhere
and  found the Singleton pattern interesting ( to say the least )
 
 Here a simple *C Sharp* implementation :
 
 class Singleton
   {
     private static Singleton instance;
 
     // Note: Constructor is 'protected'  ...  why not private ?
     protected Singleton() 
     {
     }
 
     public static Singleton Instance()
     {
       // Use 'Lazy initialization' 
       if (instance == null)
       {
         instance = new Singleton();
       }
 
       return instance;
     }
   }
 
 My thoughts
 D classes do not have nessesarily an constructor.
 OR How would you implement this pattern D
 
 In general :
 Patterns allways have a bad side-effect, you can not really re-use them. 
 What about using D MIXINS/ MIXIN Templates and Interfaces to make pattern more
re-useable, more universal . Opinions ?
 
 regarding the singleton :
 (probabely a quit stupid question)
 What about static this()... can this D feature be usefull
 
 Many Thanks in advance Bjoern
 

http://dblog.aldacron.net/2007/03/03/singletons-in-d/
May 11 2007
prev sibling parent Manfred Nowak <svv1999 hotmail.com> writes:
BLS wrote
 found the Singleton pattern interesting

http://www.digitalmars.com/d/archives/21642.html -manfred
May 12 2007