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

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/

> 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

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

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/

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
HaHa, funny. <bg>
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

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.

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/

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/

> 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