Why Singletons are Evil

re: Why Singletons are Evil

Scott Allen — Tue, 25 May 2004 03:41:00 GMT

I agree singletons are the source of many problems that start in design and end in debugging. I certainly agree with point #1 and #4. As for #2, and #3, I don't find those points as convincing. I could be bastardizing the textbook definition or misunderstanding, but these points seem to imply a singleton needs to be a class with all static / shared fields and methods. I tend to think of a singleton along the lines of #2, whereby a factory returns the single instance of an object. The single object can be polymorphic which offers different implementations for the same contract established by a base class or interface.

That being said, I’ve seen so many people in newsgroups run into problems with singletons. Many of these problems fall into point #1, whereby the problem they are solving really doesn’t need a singleton solution, but there are also threading issues to deal with, and figuring out what to do if the singleton creation process could throw is tricky.

Could you post the links in a comment?

re: Why Singletons are Evil

Scott Densmore — Tue, 25 May 2004 04:45:00 GMT

#2 is saying Singlton is managing a resource and a factory or builder is a better "true" option for how to create a object. #3 means that everytime you use a singlton in some other class you are not tied to that singleton and everyone who uses it... and that is same problem with globals. In todays new SO environment and given that one of testings principles is isolation, tying everone to that one singleton smells bad. Singletons have there place I am sure, just not sure I have ever come across a need for one.

And what links do you want me to post?

re: Why Singletons are Evil

damien morton — Tue, 25 May 2004 05:11:00 GMT

Singletons are a great temptation, as are static classes with public methods and private state.

I havent put this into practice yet, but I have a feeling that the IServiceProvider constellation of interfaces is a good approach to handling singletons, at least, it seems that it might be the solution in the MVC code ive been working on.

re: Why Singletons are Evil

Roaan Vos — Tue, 25 May 2004 08:38:00 GMT

I like singletons and thus can't say I agreee with everything that's been said. As with everything misusing something does make it seem evil, but used correctly it does not have to be.
Personally I see a singleton as a resource. E.g. Let's assume I'm accessing one database and have a singleton allowing all access to the database. Isn't this singleton better than having to pass a "database" class all over the code. Come to think of it, it might actaully lead to "looser" coupling since the method/class that needs access to the database can access the singleton without relying on other methods/classes having to pass the "database" object. Having the "database" class in the method signature actually tightly couples everyone to this implementation.
To clarify. Let's once again assume I have a class called "UserInfo" that loads user information. We have 4 options.
1) The "database" class is passed in the constructor.
2) The "database" class is passed to every method in "UserInfo"
3) The "UserInfo" can have an internal "Database" member variable which has to be instantiated everytime a "UserInfo" class is created. (I.e. configured etc)
4) The "UserInfo" has access to the "Database" singleton

Options (1) and (2) all mean that whoever wants to use the "UserInfo" class must pass the "Database" instance and in the process tightens coupling.
Option (3) looks ok except that the "Database" class has to be reconfigured for every instance of "UserInfo"

Having "UserInfo" manage access to the database (either via (3) or (4)) means "UserInfo" can be seen as a standalone component that is reusable by other applications.

re: Why Singletons are Evil

Brian Button — Tue, 25 May 2004 14:03:00 GMT

This idea of using a singleton to access a database whereever it is needed is the "singleton as global variable" antipattern Scott wrote about above. The main two problems I have with it are that it directly couples code to the singleton object, and it does it in a hidden way. I prefer to make dependencies between classes obvious through method signatures, if at all possible. This lets me understand a design better without having to look through the code.

The point about tightly coupling everyone to a database implementation is not entirely correct. It does couple everyone to a database interface, but it does *not* couple them to an implementation. The interface is passed where it is needed, and I can override the interface very simply to provide one-off testing implementations of it for my unit tests.

If I find myself having an object that is passed all over my code, that is not a sign to me to make that object into a singleton. It is a hint, taken from my code, that there is a different way I could have partitioned my system to avoid that piece of data becoming a tramp. I try to change the design for the better rather than introduce a global variable.

Roaan, is everything you said above equally valid if you replace "singleton" with "global variable"?

re: Why Singletons are Evil

Mikhail Arkhipov (MSFT) — Tue, 25 May 2004 15:25:00 GMT

#1 is inevitable when your system consists of tons of services (as in tens and even hundreds). Passing them around is plain impossible, you end up with too many parameters, most of them unused (methods will be passing most of its parameters to other methods without using them).

Alternatively, you may add a bunch of Get methods to other object intefaces in an attempt to let objects get to the service so when A needs B but only has C, it will call C::get_D, then D::get_E and then E::get_B.

Difference from global variable is very simple and described in patterns books: you cannot modify the object. Nothing is wrong with const global variable (read: #define).

BTW, it is much easier to refactor code with QueryService calls vs one that passes everythign around. If you don't want code to be talking to service provider, don't give service provider to it.

re: Why Singletons are Evil

Roaan Vos — Tue, 25 May 2004 16:23:00 GMT

I would not replace singleton with global variable. The reason is more personal. All my singletons are (almost completely) stateless. The only state they contain are generally configuration settings.

If I had to use global variables ;) I don't think this same restriction would apply. If the global variable had state, I would never use it. If it is stateless then I can see how global variable and singleton could be seen as the same. The problem with global variables is not that they are global, but rather the fact that anyone can change their state.

If classes use singletons, I think it is much easier changing/replacing the singleton than replacing all method signatures in a call stack etc.

PS. How about this as food for thought. What would the general comment be if I said in essence SOA's are singletons

re: Why Singletons are Evil

Brian Button — Tue, 25 May 2004 16:39:00 GMT

Mikhail,

#define and const global variables are very different things. #defines do not introduce dependencies on classes, whereas variables do. I don't understand how the cases are parallel.

As far as your other points about having a system with many services, I fear that our coding styles may be different. I definitely tend towards lots of small, special purpose classes, which usually means that one class needs a very small number of services. I don't run into the situation where one class needs to know about the entire rest of the world. And when I do, I take that as a hint from the code that the design is not as good as it could be, and I make it better.

Whether you pass the objects in or use a global method of accessing them, that module is still very tightly coupled to the entire rest of your system, and is entirely untestable at the unit level.

re: Why Singletons are Evil

Brian Button — Tue, 25 May 2004 17:54:00 GMT

Roaan,

That's an interseting point you raised about SOAs. In essence, I agree with you on that. Once again, I prefer to find a way to make their presence known, and to limit their reach into the rest of my code, as with singletons.

The issue I try to mitigate when faced with a static dependency like this is the tight coupling that this puts onto any code that calls this. Since singletons, statics, and SOAs are all direct dependencies, without the benefit of an interface on top of them, I always try to interpose a shim class over them. I create an interface for that class, and then I can use a special testing version of that class during unit testing, so I don't have to access the network, set up a server, etc. The downside of this is that I then do have to pass that service around to where it is needed. In my mind, though, that just makes public a dependency that was already there.

Most of the complexity I end up adding to systems I do to make the final system more unit-testable. I find that the act of doing this also takes me down other good roads, like forcing my code to be more modular, eliminating spiderwebs of dependencies, and things like that. All Good Things (TM).

re: Why Singletons are Evil

Scott Densmore — Tue, 25 May 2004 20:41:00 GMT

Mikhail,
I aggree with you on that. I am assuming you are talking about Visual Studio with QueryService. I think this is a good way to use singltons, and the cool thing about this is I really don't know that I am using one as far as the service is concerned. I guess this might also be concidered as a facade into my service (whatever that might be), and I agree with this approach. Of course I love Visual Studio so I guess the QueryService part does not bother me. :). Thanks for the feedback.

Singletons are not evil

public MattBerther : ISerializable — Thu, 27 May 2004 09:39:00 GMT

Scott Densmore has an interesting post regarding singletons and why he thinks they are evil. I'd like to go through his points one by one and add my thoughts: Singletons frequently are used to provide a global access point for...

Button's Law of Design Maturity

Brian Button - One Agile Coder — Wed, 18 Aug 2004 06:23:00 GMT

Button's Law of Design Maturity

More on singletons and testing

C#deSamurai — Sat, 21 Aug 2004 05:20:00 GMT

Button's Law of Design Maturity

.Text Blog — Sat, 19 Feb 2005 02:01:00 GMT

Pointer to posts mentioned in my webcast

Brian Button - One Agile Coder — Sun, 13 Mar 2005 16:59:00 GMT

re: Singleton

FoxyBlog — Mon, 19 Sep 2005 12:03:44 GMT

How to Decontaminate a Singleton at rain.webs Blog: Springsteam

How to Decontaminate a Singleton at rain.webs Blog: Springsteam — Fri, 15 Dec 2006 02:49:29 GMT

PingBack from http://blog.rainer.eschen.name/2006/12/15/how-to-decontaminate-a-singleton/

Andres’ thoughts » Finding coupled code

Andres’ thoughts » Finding coupled code — Thu, 01 Feb 2007 01:19:14 GMT

PingBack from http://www.taylor.se/blog/2006/02/01/finding-coupled-code/

Eli Lopian’s Blog (TypeMock) » Blog Archive » Evil Singleton Mocking with Natural™ Mocks

Wed, 28 Feb 2007 00:12:20 GMT

PingBack from http://www.elilopian.com/2007/02/19/evil-singleton-mocking-with-natural-mocks/

Antipatrones de dise??o « Complejidad Ciclom??tica

Antipatrones de dise??o « Complejidad Ciclom??tica — Fri, 25 May 2007 13:29:46 GMT

PingBack from http://complejidad.wordpress.com/2007/05/25/antipatrones-de-diseno/

Software As She’s Developed » Blog Archive » The only thing wrong with GoF Design Patterns is …

Thu, 26 Jul 2007 03:32:11 GMT

PingBack from http://www.softwareas.com/the-only-thing-wrong-with-gof-design-patterns-is

learn spanish free online course

learn spanish free online course — Thu, 13 Sep 2007 22:54:34 GMT

learn spanish free online course

hide comments friends myspace code

hide comments friends myspace code — Tue, 18 Sep 2007 11:19:06 GMT

hide comments friends myspace code

nwebb.co.uk » Blog Archive » Using Cairngorm & Thoughts On Handling Those Pesky Singletons

Sat, 12 Apr 2008 17:31:42 GMT

PingBack from http://nwebb.co.uk/blog/?p=168

Beginning with Singleton .Instance Peekaboo, and Ending Up with Why Singleton At All?

Incoherent Rambling — Mon, 28 Apr 2008 12:25:24 GMT

I know the title of this post is weird, but just bear with me a moment... Often time I found myself writing

Singletons Are Good « SoftestPawn’s Weblog

Singletons Are Good « SoftestPawn’s Weblog — Thu, 29 May 2008 22:37:19 GMT

PingBack from http://softestpawn.wordpress.com/2008/05/29/singletons-are-good/

Design Patterns - A deep dive 3

IT.Wox, always — Mon, 07 Jul 2008 21:22:01 GMT

Design Patterns - A deep dive 3

An ActionScript Singleton « flexdesigner

An ActionScript Singleton « flexdesigner — Thu, 28 Aug 2008 10:39:18 GMT

PingBack from http://flexdesigner.wordpress.com/2008/08/28/an-actionscript-singleton/

Design Patterns are not from Hell « Teh Grumpy Dude’s Weblog

Design Patterns are not from Hell « Teh Grumpy Dude’s Weblog — Tue, 09 Sep 2008 14:55:57 GMT

PingBack from http://tehgrumpydude.wordpress.com/2008/09/09/design-patterns-are-not-from-hell/

ANT script good practices - few thoughts « Piotr Gabryanczyk’s Blog

ANT script good practices - few thoughts « Piotr Gabryanczyk’s Blog — Mon, 15 Sep 2008 15:44:55 GMT

PingBack from http://piotrga.wordpress.com/2008/09/15/ant-script-good-practices-few-thoughts/

Singleton I love you, but you're bringing me down | // Coding Without Comments

Singleton I love you, but you're bringing me down | // Coding Without Comments — Thu, 09 Oct 2008 05:58:32 GMT

PingBack from http://www.codingwithoutcomments.com/2008/10/08/singleton-i-love-you-but-youre-bringing-me-down/

The Curse of the Singleton « Infovark Underground

The Curse of the Singleton « Infovark Underground — Wed, 19 Nov 2008 20:17:43 GMT

PingBack from http://underground.infovark.com/2008/11/19/the-curse-of-the-singleton/

The Sharendipity Blog » Simple Pseudo-threading in ActionScript

The Sharendipity Blog » Simple Pseudo-threading in ActionScript — Thu, 18 Dec 2008 23:15:33 GMT

PingBack from http://blog.sharendipity.com/simple-actionscript-pseudo-threads

Uzaya Roket G??ndermiyoruz ki, Yap Gitsin Yahu! » Don Ki??ot

Uzaya Roket G??ndermiyoruz ki, Yap Gitsin Yahu! » Don Ki??ot — Mon, 29 Dec 2008 09:54:59 GMT

PingBack from http://www.fikribol.com/donkisot/?p=113

Frage zu UnitTests in VS 2008 | hilpers

Frage zu UnitTests in VS 2008 | hilpers — Sun, 18 Jan 2009 13:47:59 GMT

PingBack from http://www.hilpers.com/1174751-frage-zu-unittests-in-vs

C#: Pattern Singleton - Zaragon blog

C#: Pattern Singleton - Zaragon blog — Wed, 04 Mar 2009 01:56:09 GMT

PingBack from http://blog.adrweb.net/2009/01/27/c-pattern-singleton/

The Grimoire » Singled Out

The Grimoire » Singled Out — Wed, 11 Mar 2009 05:28:03 GMT

PingBack from http://codex.grimoire.ca/2009/03/10/singled-out/

New Adventures in Software » Random Number Generators: There should be only one

Sat, 28 Mar 2009 01:15:44 GMT

PingBack from http://blog.uncommons.org/2009/01/11/random-number-generators-there-should-be-only-one/

What’s wrong with Singleton? « Hoa Chau’s weblog

What’s wrong with Singleton? « Hoa Chau’s weblog — Mon, 20 Apr 2009 10:10:22 GMT

PingBack from http://hoachau.wordpress.com/2009/04/20/whats-wrong-with-singleton/

Stupid evil cancerous liars, I hate you! « Luke Halliwell’s Weblog

Stupid evil cancerous liars, I hate you! « Luke Halliwell’s Weblog — Thu, 23 Apr 2009 14:51:28 GMT

PingBack from http://lukehalliwell.wordpress.com/2009/04/23/stupid-evil-cancerous-liars-i-hate-you/

Being Scott Densmore Why Singletons are Evil | Cast Iron Cookware

Being Scott Densmore Why Singletons are Evil | Cast Iron Cookware — Wed, 03 Jun 2009 22:47:11 GMT

PingBack from http://castironbakeware.info/story.php?title=being-scott-densmore-why-singletons-are-evil

You’re Not Your Data Access

Rob Conery — Fri, 12 Jun 2009 06:51:48 GMT

Seems I touched off a bit of a “swirl” with a comment I made on my last blog post: I think, in general

You???re Not Your Data Access

You???re Not Your Data Access — Fri, 12 Jun 2009 15:04:32 GMT

PingBack from http://buildesignwebsite.com/you%e2%80%99re-not-your-data-access/

You???re Not Your Data Access

You???re Not Your Data Access — Fri, 12 Jun 2009 17:03:15 GMT

PingBack from http://buildesignwebsite.com/you%e2%80%99re-not-your-data-access-2/