Comments on: Root Cause of Singletons

By: Singletons : Is Anti-Pattern? « Technical Jottings

Singletons : Is Anti-Pattern? « Technical Jottings — Wed, 02 Dec 2009 07:08:24 +0000

[...] in few cases and there are some “cleaner” ways of achieving singleton benefits. Here, Misko clearly points that Singletons are useful when there is one way flow in the [...]

By: Another Architectural Framework, But Why? « shaun smith

Another Architectural Framework, But Why? « shaun smith — Wed, 29 Apr 2009 12:48:29 +0000

[...] standard Singleton implementation (that static getInstance method) is severely flawed. Unless you are writing device drivers, there is almost no excuse to touch a [...]

By: How to do Everything Wrong with Servlets

How to do Everything Wrong with Servlets — Wed, 08 Apr 2009 18:43:29 +0000

[...] use global state and singletons for inter servlet communication (which we have covered in detailed here, here, and [...]

By: AS3 Dependency Injection and [Autowire] « shaun smith

AS3 Dependency Injection and [Autowire] « shaun smith — Thu, 26 Mar 2009 11:42:09 +0000

[...] Alternatively, you could use a Singleton to hang all your objects on. That would not be cool: link, link, link. [...]

By: misko

misko — Tue, 24 Feb 2009 15:53:59 +0000

@Chris,

no, the issue I have with singletons is that they represent global state. You can call them whatever you want but the moment you access any abject through a global variable you will have an issue with testability and maintainability of the code. Moreover the globality is transitive, so once you get a hold of a global variable anything you can get a hold of from there is global as well. A single global variable can expose a large mutable state to an application which is global.

By: Chris Hopman

Chris Hopman — Tue, 24 Feb 2009 09:13:23 +0000

Whatever is absolutely correct. You have a problem with a particular Singleton implementation, not the Singleton design pattern. I’m going to assume that you don’t know the difference rather than that you are deliberately setting up a straw man.So, basically your Singleton implementation can be used as follows:singleton.init();singleton.do_something();That is you have a Singleton instance singleton that must have init() called before it can be used. This seems to be due to your desire for constructors to not actually construct objects. If you want to lazily construct your object, as long as you aren’t directly exposing your internals, there is no need for for users to explicitly do the initialization. In fact, such a requirement smells bad, you should make it difficult for users to misuse your code. Almost all implementations I’ve seen require you to call a method to get a reference to the singleton instance. In this method, init() is called if needed. With this pattern, the singleton instance can even expose its internals without worry of them not being initialized. That is, the above code would change tosingleton::instance().do_something();If you don’t want the instance() method, then as long as initialization is checked and done in each of the singleton’s methods and it doesn’t expose its internals you can have the interface that you wanted. That is, you could do:singleton.do_something();Either of these solutions completely solve your original complaint about the Singleton design pattern. Again, it seems your problem is with a particular implementation that with the pattern itself.

By: Witold Szczerba

Witold Szczerba — Sun, 15 Feb 2009 22:57:07 +0000

Thank you Misko for great blog. I have never heard anyone explaining the difficult things you say like this. I just read it and it hits me like a thunder: “damn, he has got the point just-like-that while I couldn’t find it for long time” Keep dooing your great job, do not worry because all those guys who does not get the idea.

By: Alan Pinstein

Alan Pinstein — Wed, 07 Jan 2009 19:37:46 +0000

Misko-Thanks for all of these posts and your Google Clean Code talks. I watched those first, and while I was convinced of the need to do as you explained, I didn’t see HOW. This series of blog posts with concrete examples has definitely helped me see ways to refactor away from Singletons. Thanks,Alan

By: Interfacing with hard-to-test third-party code

Interfacing with hard-to-test third-party code — Sun, 04 Jan 2009 19:30:33 +0000

[...] notice that the no argument constructor is forcing me to use global state, which is very bad, but in the case of servlets I have no choice. However, I make sure that only [...]

By: The Phantom Inspector » Recording and validating NSNotifications in Objective-C Unit Tests

Sun, 21 Dec 2008 22:49:32 +0000

[...] NSNotificationCenter is basically a global context which is used by many classes. As Miško Hevery points out, global state makes testing hard. So if I decided to be pedantic about avoiding global state and [...]