So, "don't use Singleton" ?

So I've read "Singleton I love you, but you're bringing me down" at http://www.codingwithoutcomments.com/ and the articles it refers to. And it makes sense, basically.

In my latest code, I created one Singleton (see http://geekswithblogs.net/AngelEyes/archive/2011/07/21/code-worth-remembering-singleton-implemented-in-c-4.0.aspx ) and had it hold the reference to my global factory, which, I guess, makes it a service locator. The factory itself uses (and hides from the rest of the code) Ninject 2.0. As long as that will stay the only Singleton, and hold no state other than the Kernel, then I'm safe :)

posted @ Wednesday, August 17, 2011 5:41 PM
Print

Comments on this entry:

# re: So, "don't use Singleton" ?

Left by Ryan at 8/17/2011 10:07 PM
Gravatar
It seems the online community bounces between extremes. I've found that there's a good balance between using singletons and dependency injection. I use DI for anything I will be unit testing -- the idea of 100% coverage is a waste of resources -- like my domain model and services that operate on/near the domain. For my UI level and things like email services, auditing, or unit of work managers (see Ayende's blog) I tend to use static classes because I'll only ever be doing integration level testing and static calls really clean the code up.

# @ Ryan

Left by angel eyes at 8/18/2011 1:10 AM
Gravatar
I agree with the basic idea, Ryan, of using the right tool for each job.
Keep in mind, though, that static classes and methods live 'forever', so you should check what state they might hold.

The other side of that coin, of course, is that static methods load up at application start, and don't need to be reloaded later, right?

And another point to strengthen your argument is that in real world programming, you don't really always have time for perfect code, and OOP isn't the only way to go.

Your comment:



(not displayed)

 
 
 
 
 

Live Comment Preview: